You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Randy Kobes <ra...@theoryx5.uwinnipeg.ca> on 2004/06/25 21:42:21 UTC
[mp2] additional apr-ext tests
I've converted some more of the t/apr/ tests so as to test
them under t/apr-ext/ - these are contained in the attached
diff (which is quite large, hence I just attached it). This
might be useful for testing for "hidden" mod_perl.so
dependencies in the APR::* modules. One can use this neat
feature of Apache-Test:
perl t/TEST --no-httpd apr-ext
to test these without starting Apache (thanks, Geoff!).
The tests in t/apr/ that aren't included here involve
APR::Brigade, APR::OS, and APR::SockAddr.
--
best regards,
randy
Re: [mp2] additional apr-ext tests
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 25 Jun 2004, Randy Kobes wrote:
> I've converted some more of the t/apr/ tests so as to test
> them under t/apr-ext/ - these are contained in the attached
> diff (which is quite large, hence I just attached it).
[ ... ]
I've also attached another diff, for t/apr-ext/table.t,
incorporating the tests within t/apr/table.
--
best regards,
randy
Re: [mp2] additional apr-ext tests
Posted by Stas Bekman <st...@stason.org>.
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:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] additional apr-ext tests
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Mon, 28 Jun 2004, Stas Bekman wrote:
> Randy Kobes wrote:
> > On Mon, 28 Jun 2004, Stas Bekman wrote:
> >
> >>Stas Bekman wrote:
> >
> > [ ... ]
> >
> >>I think it's possible to abstract the apr tests into
> >>self-contained units, independent of the client (not to
> >>rely on $r, and other apache parts). and then we could run
> >>each of those tests twice, once under mp2 and once more
> >>standalone. Though decoupling from $r may prove hard,
> >>since some tests use $r extensively internally.
> >
> >
> > That's a great idea, and I think it's possible for many of
> > the tests with a few tweaks. What about the following
[ ... ]
> > 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?
[ ... ]
> $r is confusing here.
>
> > plan tests => 27;
> > $pool = $r;
> > }
> > else {
> > plan $r, tests => 27;
> > $pool = $r->pool;
> > }
> > # etc
> > Apache::OK;
> > }
> > 1;
That's true - it'd be better to do as you suggest below,
with putting all the modperl tests in their own area.
> I think it's better to abstract the unit tests into a
> subroutine and call it from handler() inside the modperl
> tests and directly from apr-ext tests.
>
> > ============================================================
> > To maybe simplify things, we could just pass in a
> > $pool from t/apr-ext/*.t all the time, whether
> > or not it's used?
> >
> > Some of the tests use $r in an "incidental" way (eg, to get
> > a file in finfo.pm), but these can use some other thing that
> > doesn't rely on Apache. Some others have subtests that are
> > httpd-specific, but we could just skip those for the
> > external tests. Finally, $r->notes is used at times, but we
> > could do something like
> > my $table = ($is_running_apr_external) ?
> > APR::Table::make($pool, 2) : $r->notes;
>
> then why not using a new table at all times, instead of $r->notes?
we could do that, as a table and $r->notes have
similar usage.
> > 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?
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.
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?
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] additional apr-ext tests
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Mon, 28 Jun 2004, Stas Bekman wrote:
>
>
>>Stas Bekman wrote:
>
> [ ... ]
>
>>I think it's possible to abstract the apr tests into
>>self-contained units, independent of the client (not to
>>rely on $r, and other apache parts). and then we could run
>>each of those tests twice, once under mp2 and once more
>>standalone. Though decoupling from $r may prove hard,
>>since some tests use $r extensively internally.
>
>
> That's a great idea, and I think it's possible for many of
> the tests with a few tweaks. What about the following
> approach? For t/apr-ext/, the *.t files could be of two
> types: one that doesn't require a pool:
> =====================================================
> # test APR::Util
> use strict;
> use warnings FATAL => 'all';
> use lib qw(t/response);
> require TestAPR::util;
> TestAPR::util::handler();
> ==================================================
> and another that does:
> =================================================
> # Testing APR::URI (more tests in TestAPI::uri)
> use strict;
> use warnings FATAL => 'all';
> use lib qw(t/response);
> require TestAPR::uri;
> use APR::Pool ();
> my $pool = APR::Pool->new();
> TestAPR::uri::handler($pool);
> ========================================================
> Then, in the t/response/TestAPR/*.pm modules, we fix
> things within the handler accordingly: if no pool
> is required:
> ======================================================
> package TestAPR::util;
> # test APR::Util
> use strict;
> use warnings FATAL => 'all';
> use Apache::Test;
> use Apache::TestUtil;
> use APR::Util ();
> use Apache::Const -compile => 'OK';
> 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.
> ======================================================
> and if a pool is required:
> =====================================================
> package TestAPR::uri;
> # Testing APR::URI (more tests in TestAPI::uri)
> use strict;
> use warnings FATAL => 'all';
> use Apache::Test;
> use Apache::TestUtil;
> use APR::URI ();
> use Apache::Const -compile => 'OK';
> # snipped
> sub handler {
> my $r = shift;
> my $pool;
> if (ref($r) eq 'APR::Pool') {
$r is confusing here.
> plan tests => 27;
> $pool = $r;
> }
> else {
> plan $r, tests => 27;
> $pool = $r->pool;
> }
> # etc
> Apache::OK;
> }
> 1;
I think it's better to abstract the unit tests into a subroutine and call it
from handler() inside the modperl tests and directly from apr-ext tests.
> ============================================================
> To maybe simplify things, we could just pass in a
> $pool from t/apr-ext/*.t all the time, whether
> or not it's used?
>
> Some of the tests use $r in an "incidental" way (eg, to get
> a file in finfo.pm), but these can use some other thing that
> doesn't rely on Apache. Some others have subtests that are
> httpd-specific, but we could just skip those for the
> external tests. Finally, $r->notes is used at times, but we
> could do something like
> my $table = ($is_running_apr_external) ?
> APR::Table::make($pool, 2) : $r->notes;
then why not using a new table at all times, instead of $r->notes?
> 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().
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] additional apr-ext tests
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Mon, 28 Jun 2004, Stas Bekman wrote:
> Stas Bekman wrote:
[ ... ]
> I think it's possible to abstract the apr tests into
> self-contained units, independent of the client (not to
> rely on $r, and other apache parts). and then we could run
> each of those tests twice, once under mp2 and once more
> standalone. Though decoupling from $r may prove hard,
> since some tests use $r extensively internally.
That's a great idea, and I think it's possible for many of
the tests with a few tweaks. What about the following
approach? For t/apr-ext/, the *.t files could be of two
types: one that doesn't require a pool:
=====================================================
# test APR::Util
use strict;
use warnings FATAL => 'all';
use lib qw(t/response);
require TestAPR::util;
TestAPR::util::handler();
==================================================
and another that does:
=================================================
# Testing APR::URI (more tests in TestAPI::uri)
use strict;
use warnings FATAL => 'all';
use lib qw(t/response);
require TestAPR::uri;
use APR::Pool ();
my $pool = APR::Pool->new();
TestAPR::uri::handler($pool);
========================================================
Then, in the t/response/TestAPR/*.pm modules, we fix
things within the handler accordingly: if no pool
is required:
======================================================
package TestAPR::util;
# test APR::Util
use strict;
use warnings FATAL => 'all';
use Apache::Test;
use Apache::TestUtil;
use APR::Util ();
use Apache::Const -compile => 'OK';
sub handler {
my $r = shift;
if ($r) {
plan $r, tests => $password_validate_tests;
}
else {
plan tests => $password_validate_tests;
}
# etc
Apache::OK;
}
1;
======================================================
and if a pool is required:
=====================================================
package TestAPR::uri;
# Testing APR::URI (more tests in TestAPI::uri)
use strict;
use warnings FATAL => 'all';
use Apache::Test;
use Apache::TestUtil;
use APR::URI ();
use Apache::Const -compile => 'OK';
# snipped
sub handler {
my $r = shift;
my $pool;
if (ref($r) eq 'APR::Pool') {
plan tests => 27;
$pool = $r;
}
else {
plan $r, tests => 27;
$pool = $r->pool;
}
# etc
Apache::OK;
}
1;
============================================================
To maybe simplify things, we could just pass in a
$pool from t/apr-ext/*.t all the time, whether
or not it's used?
Some of the tests use $r in an "incidental" way (eg, to get
a file in finfo.pm), but these can use some other thing that
doesn't rely on Apache. Some others have subtests that are
httpd-specific, but we could just skip those for the
external tests. Finally, $r->notes is used at times, but we
could do something like
my $table = ($is_running_apr_external) ?
APR::Table::make($pool, 2) : $r->notes;
Does the above sound like a reasonable approach?
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] additional apr-ext tests
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> Randy Kobes wrote:
>
>> I've converted some more of the t/apr/ tests so as to test
>> them under t/apr-ext/ - these are contained in the attached
>> diff (which is quite large, hence I just attached it). This
>> might be useful for testing for "hidden" mod_perl.so
>> dependencies in the APR::* modules. One can use this neat
>> feature of Apache-Test:
>> perl t/TEST --no-httpd apr-ext
>> to test these without starting Apache (thanks, Geoff!).
>>
>> The tests in t/apr/ that aren't included here involve
>> APR::Brigade, APR::OS, and APR::SockAddr.
>
>
> I'm not sure that duplicating tests is a good idea. If we do so we will
> have to maintain two sets of mostly identical tests. I think that
> apr-ext could just test loading of the modules, a few basic tests (or
> none at all) and those features unique to APR, which aren't used under
> mod_perl (if there are such at all). So basically what I think we need
> is to just one test that loads all the modules. And a few more tests
> testing things like pool management. Thoughts?
I think it's possible to abstract the apr tests into self-contained units,
independent of the client (not to rely on $r, and other apache parts). and
then we could run each of those tests twice, once under mp2 and once more
standalone. Though decoupling from $r may prove hard, since some tests use $r
extensively internally.
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] additional apr-ext tests
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> I've converted some more of the t/apr/ tests so as to test
> them under t/apr-ext/ - these are contained in the attached
> diff (which is quite large, hence I just attached it). This
> might be useful for testing for "hidden" mod_perl.so
> dependencies in the APR::* modules. One can use this neat
> feature of Apache-Test:
> perl t/TEST --no-httpd apr-ext
> to test these without starting Apache (thanks, Geoff!).
>
> The tests in t/apr/ that aren't included here involve
> APR::Brigade, APR::OS, and APR::SockAddr.
I'm not sure that duplicating tests is a good idea. If we do so we will have
to maintain two sets of mostly identical tests. I think that apr-ext could
just test loading of the modules, a few basic tests (or none at all) and those
features unique to APR, which aren't used under mod_perl (if there are such at
all). So basically what I think we need is to just one test that loads all the
modules. And a few more tests testing things like pool management. Thoughts?
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org