httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: using TestRunPerl without mod_perl.c
Date Sat, 04 Oct 2003 19:12:53 GMT
Geoffrey Young wrote:
>> TestRunPerl implies that mod_perl is available. If it is not, 
>> TestRunPerl should abort *before* it creates the config file, telling 
>> user to use a mod_perl enabled server. 
> I don't think it needs to be that way, and I'm not even sure it's a good 
> idea.  here's why...
> I may have a distribution that has parts that can work in both 
> environments.  say I'm writing a test for - I maybe want to have 
> tests that use no server (generate HTML foo), then test stuff like 
> $q->param, which behaves differently under mod_perl and mod_cgi.
> TestRunPerl is useful for configuring the mod_perl part of the server, 
> but I don't necessarily want the _entire test suite_ to blow up just 
> because mod_perl isn't in the httpd the user provided - there are still 
> at least two parts of the module I can test.  granted, with something as 
> simple as I may not need the mod_perl widgets, but for other, 
> more elaborate, modules I may.  and the functionality for configuring 
> mod_perl widgets is right there in TestRunPerl - no need for me to do it 
> myself, either manually or through a subclass.
> now, say you have a mod_perl-only module, like some of the ones we have 
> both written.  you have a choice: you either want the tests to fail if 
> mod_perl isn't present (like you do) or you want the tests to skip (like 
> I do).
> the patch I have proposed allows both to coexist.  for me, I can do
> plan tests => 1, have_module('mod_perl.c');
> while you can do
> die unless have_module('mod_perl.c');
> plan tests => 1;
> the end result is that everybody can achieve the behavior they want, 
> which is kinda what Perl is all about :)

That requires too much duplicated code in all tests if the whole test suite 
requires mod_perl.

>> There is nothing wrong with your patch, but it hides the problem 
>> instead of fixing it.
> we clearly have different views of the problem.  I think that 
> Apache-Test should provide the tools to configure a server and run the 
> tests, leaving it up to the tests to decide what fails and what passes.  
> by making TestRunPerl (or anything else, for that matter) abort if a 
> specific httpd module isn't found, you are taking away flexibility that 
> would benefit test authors.
> in other words, Apache-Test should provide tools to make creating a test 
> enviroment easier, not make decisions about whether 'make test' passes 
> or fails.

Agreed. But that doesn't necessarily have to happen in TestRunPerl, 
Apache-Test != TestRunPerl, and TestRunPerl != Apache-Test

There are a few ways to solve this conflict.

1) Have more than just TestRunPerl. e.g., keep TestRunPerl as it is (mod_perl 
stuff is not opted by IfModule modperl) and fix it to die during the config 
phase if mod_perl is not available. And add a subclass of TestRun which will 
allow mod_perl to be optional. Bother can re-use most of the code.

2) Clean TestRunPerl to protect all mp directives with 'IfModule modperl', add 
a new() option which will force a require of mp, or the opposite, have the mp 
required by default, but have an option that will make it optional. I believe 
we want to go with the latter, since most Apache:: modules on CPAN will 
require mp to be available.

The first option is better for the end user[1], since they just need to pick 
the right class and they have their httpd.conf with little IfMdodule noise. 
But it requires more coding on the developer's side.

The second option makes it easier on developers, but harder on users[1], since 
now they have to figure out the extra options and they end up with a noisier 

*1 user == a 3rd party module developer.

How does that sound to you?

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

View raw message