httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: Apache::TestMB
Date Tue, 22 Jun 2004 21:44:35 GMT
David Wheeler wrote:

>> How are you going to avoid that? I mean your users need to be able to 
>> run certain features of Apache-Test, which are beyond 'make test'. May 
>> be you want to always create t/TEST, but run 'make test' without 
>> invoking t/TEST?
> 
> 
> I meant that I wanted to avoid dealing with it. ;-) The current approach 
> works, but if I get rid of t/TEST, I would have to deal with it. The 
> only other approach would be if this stuff was abstracted into a 
> function or method in Apache::TestRun. Then I could just call it with 
> the appropriate arguments.

It may be a fairly complex logic to add, though you could write wrappers that 
simply push things into @ARGV, emulating the command line.

Though I'd rather have one way to do things. It's already a non-trivial thing 
with all the multiple options. If we have to explain to the user in trouble 
with the test suite more than one way to help us show their problems, it makes 
things even more complex and confusing. So if you can keep t/TEST as it is I 
think it'll be a good thing. Feel free to convince me otherwise. Admittedly I 
have never used MB, so I may miss some things.

>> there is no C, there is perl that creates the necessary build 
>> environment.
>  
> Oh, sorry. Where do I find it?

Somewhere around that code that deals with cmodules:

   grep -Ir cmodules Apache-Test/lib/Apache/

>> Yes please, we use 4 everywhere.
> 
> 
> Ick. Done. I only noticed two spaces in one place in generate_script(). 
> Unless you want lines following an opening paren (as in the calls to 
> do_system()) to be indented only 4 spaces, rather than lined up with the 
> previous line?

No, no, it's fine. But don't worry, once the patch is finished I'll go over it 
to make it consistent with the rest of the code. Most of things are just perfect.

>> I meant the fact that '$script.PL' doesn't interpolate $script.
> 
> 
> Oh, duh. Fixed.

I guess that part of the code is not really tested :)

>>>> Also you can use shortcuts from Apache::TestTrace to do logging.
>>>
>>> Um, I have no idea what you're talking about here. Sorry.
>>
>>
>> use Apache::TestTrace;
>>
>> debug "foo";
>>
>> error "bar";
>>
>> etc...
>>
>> The tracelevel will automatically enable and disable various trace 
>> levels. See Apache::TestTrace for more info.
> 
> 
> Um, okay, but what needs to change in TestMB.pm to address this? Is 
> there something missing? I didn't notice anything about this in TestMM.pm.

Instead of:

print "Bar tar car\n";

use Apache::TestTrace;

debug "Bar tar car\n";

Now replace debug with whatever level you want this message to be printed at. 
By default the trace level is 'info', so unless user changes the default, traces:

   emerg alert crit error warning notice info

will always log things, whereas debug() won't. So for example in your case you 
could use the notice() func. Apache::TestTrace really mimicks the LogLevel 
from Apache.

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Mime
View raw message