httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: Apache::TestMB
Date Tue, 22 Jun 2004 22:15:06 GMT
David Wheeler wrote:
> On Jun 22, 2004, at 2:44 PM, Stas Bekman wrote:
>> 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.
> I'll leave it; I don't have the tuits to change it. I'm just happy to 
> have something that works with Module::Build. My only thought was that 
> t/TEST seemed like a hack to get something Perlish to work in a C<make> 
> environment. And since Module::Build is a Perl environment, that hack is 
> no longer necessary. But I recognize that there has been a lot built up 
> around that hack, so it's much simpler to follow the 80/20 rule and get 
> it done the way it is.

Yes, but it won't work for modules not using MB, so it's better to have 
something common. We can always change things later if we find it beneficial. 
Nothing is cast in stone as long as it doesn't add a huge overhead for the 
user's learning curve.

>> Somewhere around that code that deals with cmodules:
>>   grep -Ir cmodules Apache-Test/lib/Apache/
> Yes, Randy has been pointing it out. But does TestMB need this support 
> in an initial release? Seems like those who depend on the Makefile will 
> keep using TestMM for a while.

I doubt so. Just make it die with the appropriate message, so that if someone 
needs it they will know that it'll be added in the future.

>> 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 figured. I like my style, too (mainly just cperl-mode style). ;-)

pretty much the same here, cperl-mode too :)

>>>> 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 :)
> I never, *ever,* create my own t/TEST.PL, so no, it isn't.

generate_script does it for you too.

>> 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.
> Are you suggesting that it be used inside Apache::TestMB? There's only 
> one print statement, in generate_script(), and there I followed the 
> approach of Module::Build, even though TestMM used info.

It doesn't matter for now. I was just mentioning a feature that you may find 

> So, what more do you need before committing this puppy? I'm ready to 
> take advantage of it with my module and upload that module to CPAN! ;-)

It'd be nice to actually try your patch in action with some module that uses 
MB before committing it. Other than that +1 and thank you, David.

Moreover, I think it's time to give you commit access to A-T if you wish to. 
Do you have an account at

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

View raw message