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 CGI.pm - 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 CGI.pm 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 httpd.conf.
*1 user == a 3rd party module developer.
How does that sound to you?
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
