Christopher H. Laco wrote:
So According to http://perl.apache.org/docs/general/testing/testing.html#C_Apache__TestSmoke__Solution
The sample t/SMOKE.PL files is:
#file:t/SMOKE.PL #--------------- #!perl
use strict; use warnings FATAL => 'all';
use FindBin; use lib "$FindBin::Bin/../Apache-Test/lib"; use lib "$FindBin::Bin/../lib";
use Apache::TestSmoke ();
Apache::TestSmoke->new(@ARGV)->run;
That uses TestSmoke, not TestSmokePerl [directly] like I would expect
That's what I currently have in my t/SMOKE.PL [sans FindBin stuffs].
I tried using a t/SMOKE.PL that used TestSmokePerl instead of TestSmoke. It wasn't pretty. :-)
When you see Perl in the class name, it really means ModPerl-specific. i.e. it's a subclass that *requires* mod_perl and needed to be be able to run under mod_perl.
And maybe that's my issue.
After looking at it again, I get the feeling that t/SMOKE for an A-T dist using mod_perl really wants to use TestSmokePerl instead of TestSmoke; and TestSmokePerl looks much much thinner than TestRunPerl in terms of the mod_perl configuration steps in the module.
No. A-T is not mod_perl specific, therefore it's t/SMOKE must not require mod_perl.
Assuming it's the right thing to do, adding the mod_perl config stuff into TestSmokePerl from TestRunPerl shouldn't be too difficult.
I'm afraid of breaking anything that uses TestSmokePerl, but it doesn't appear like much, if anything does?
All the changes should go into base class, which is TestSmoke. TestSmokePerl should have only modperl specific things, just like ModPerl::TestRun subclasses Apache::TestRun.
-- __________________________________________________________________ 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
