Randy Kobes wrote:
sub handler { my $r = shift; if ($r) { plan $r, tests => $password_validate_tests; } else { plan tests => $password_validate_tests; } # etc Apache::OK; } 1;
plan $r is needed for 'sethandler modperl', the normal plan should work with 'perl-script'. One only needs to set the header explicitly.
So use perl-script for all the apr tests?
to make ok() work, yes. Or may be we should do similar to what 'plan $r, ...' does, using the tie STDOUT trick. It sounds that perl-script is just simpler.
Does the above sound like a reasonable approach?
More or less yes. I think the approach should be the other way around. Make the test units work in apr-ext and then it should be trivial to make the modperl tests to run them as well. The modperl specific tests will stay where they are, i.e:
apr-ext/foo.t: -------------- Foo::test()
apr/response/TestAPR/foo.pm --------------------------- ... sub handler { $r->content_type... Foo::test(); modperl_specific_tests(); OK }
where Foo::test is self-contained, starting with plan().
That would be clearer ... Where should Foo::test live? Under something like response/TestAPR-ext?
How about introducing t/lib which will be automatically put in @INC by Apache-Test? And keep all the shared between tests code there?
One thing with the above is that, currently, there are some apr subtests that use (and test) specific things within mod_perl. If Foo::test started with plan(), there would have to be a way to tell it that modperl_specific_tests() is following, in the case of modperl tests, and otherwise not. Perhaps using it like Foo::test(extra => 4); which would mean 4 additional (modperl specific) tests are following, in addition to the modperl-independent tests already within Foo::test.
We could do that. Or we could simply have two independent tests, keeping things simple.
Another issue is the use of a pool within the tests (and also the use of a table as discussed above). Right now some of the tests use $r->pool and $r->notes, which within Foo::test would have to be converted to an APR::Pool->new() and APR::Table::make($pool, $n) to work without mod_perl. But perhaps it'd be useful to test the $r->pool and $r->notes explicitly within mod_perl (this also might be relevant for using the tests as a user's guide). What about having Foo::test function as Foo::test(pool => $r->pool, notes => $r->notes); where, if $r->pool is passed, that's used as the pool, and if $r->notes is passed, that's used as the table?
I think we better separate those things completely. If the notes table is not being tested, but just used as a tool for a test, we can be replace it with another table (APR::Table::make($pool, $n)). If however the notes table is a part of the test it's the best to leave it out for the special modperl specific test. Same goes for pool and any other objects (it's definitely not an option to replace $r->pool in APR::Pool test, since internally it behaves totally different than the custom pool).
So the approach should probably be like so:
- see if the tests uses mp features as a tool for testing - if so, try to replace it with non-mp specific code - otherwise, split those tests into a separate, mp-specific test
We may end up with things that may seem like duplication, but in reallity that won't be the case, since different objects will be tested (again giving the example of $r->pool and a custom pool).
-- __________________________________________________________________ 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
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
