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/07/13 06:16:50 UTC
[mp2] common apr/apr-ext tests
I've been working at reworking some of the apr
tests so that they can also function as apr-ext
tests, with as much common code as possible.
I have a working set, but before getting into
specifics, thought it'd be good to discuss some
of the design issues first.
As Stas suggested in some earlier messages,
one could put the common tests in one package,
and then call it from both t/apr/ and t/apr-ext/.
So the simplest tests (eg, constants.t), would
look like:
==============================================
# file t/apr-ext/constants.t
use lib qw(t);
require aprlib::constants;
aprlib::constants::test();
==============================================
for the t/apr-ext/ tests, and
==============================================
# file t/apr/constants.t
use lib qw(t);
require aprlib::constants;
aprlib::constants::test();
==============================================
for the t/apr/ tests, where the common
tests use
=============================================
# file t/aprlib/constants.pm
use Test;
# etc
sub test {
plan tests => 5;
ok 1;
# etc
}
1;
============================================
So the first question I had - is there a better
name and/or location than "t/aprlib/" to put
in the common code?
However, all the other tests require something
more complex, as the corresponding t/apr/ tests
use $r explicitly. What about the following
model? For some test foo, one has
==============================================
# file t/apr-ext/foo.t
use lib qw(t);
require aprlib::foo;
aprlib::foo::test();
==============================================
for the t/apr-ext/ tests, and for the
t/apr/ tests, the corresponding response
=============================================
# file t/response/TestAPR/foo.pm
package TestAPR::foo;
use Apache::Test;
use lib qw(t);
require aprlib::foo;
# etc
sub handler {
my $r = shift;
# run common tests, and plan for 5 additional ones
aprlib::foo::test(r => $r, extra => 5);
# run 5 additional mod_perl specific tests
Apache::OK;
}
1;
=================================================
Here, the common tests look like
=================================================
# file t/aprlib/foo.pm
package aprlib::foo;
use Apache::Test;
# etc
sub test {
my %args = @_;
my $r = $args{r};
my $extra = $args{extra} || 0;
if ($r) {
plan $r, tests => 55 + $extra, some_possible_condition;
}
else {
plan tests => 55, some_possible_condition;
}
# some of the tests may want a pool
my $pool = $r ? $r->pool : APR::Pool->new();
# some of the tests may use $r->notes for a table
my $table = $r ? $r->notes : APR::Table::make($pool, 2);
# etc
}
1;
============================================================
Something that may be simpler is to use, within the
response, Apache::Test's test_pm_refresh: the apr-ext
test is the same, whereas the response would be
==========================================================
# file t/response/TestAPR/foo.pm
package TestAPR::foo;
use Apache::Test;
use lib qw(t);
require aprlib::foo;
# etc
sub handler {
my $r = shift;
# run common tests, and then run 5 additional ones
aprlib::foo::test($r);
# run 5 additional mod_perl specific tests
Apache::Test::test_pm_refresh;
plan $r, tests => 5, some_possible_condition;
# run 5 more tests
Apache::OK;
}
1;
=================================================
where here the common tests are
=================================================
# file t/aprlib/foo.pm
package aprlib::foo;
use Apache::Test;
# etc
sub test {
my $r = shift;
if ($r) {
plan $r, tests => 55, some_possible_condition;
}
else {
plan tests => 55, some_possible_condition;
}
# some of the tests may want a pool
my $pool = $r ? $r->pool : APR::Pool->new();
# some of the tests may use $r->notes for a table
my $table = $r ? $r->notes : APR::Table::make($pool, 2);
# etc
}
1;
============================================================
When running the tests using the latter, the output looks
like
t\apr\foo....ok 55/55Test header seen more than once!
t\apr\foo....ok
All tests successful
which may be a bit confusing?
I guess this could also be made simpler by, in the
common tests, always using APR::Pool and APR::Table,
but perhaps it would be good to test $r->pool and
$r->notes in an httpd environment?
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] common apr/apr-ext tests
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Tue, 13 Jul 2004, Stas Bekman wrote:
> Randy Kobes wrote:
> > I've been working at reworking some of the apr
> > tests so that they can also function as apr-ext
> > tests, with as much common code as possible.
> > I have a working set, but before getting into
> > specifics, thought it'd be good to discuss some
> > of the design issues first.
> >
> > As Stas suggested in some earlier messages,
> > one could put the common tests in one package,
> > and then call it from both t/apr/ and t/apr-ext/.
> > So the simplest tests (eg, constants.t), would
> > look like:
[ ... ]
> > So the first question I had - is there a better
> > name and/or location than "t/aprlib/" to put
> > in the common code?
>
> I'd rather see t/lib and have all those packages there, to
> clearly separate those from directories with tests. And
> adjust @INC to include those dirs.
>
> t/lib/TestAPRlib/*
Sounds good - I'll create those, and start from there.
>
> I think it's the best to split plan() away from the subs with tests. I
> think the subs should be just ok() tests, like a few wrappers that we
> have inside normal tests (e.g. the apr/pool tests has a few subs each
> declares in the comment how many tests it runs.
>
> So I propose the following plan of action. First take the simple tests
> that can be decoupled from $r and have them put into a separate sub
> moved into t/lib/..., leave the $r-dependent tests where they are, and
> to start with run from both locations just those subs which don't
> require $r.
>
> But, don't forget that we can do Apache::RequestRec->new() and voila, we
> have $r. It won't work in some cases, but may be something that will be
> just right in others. Just something to consider.
>
> Let's take one test like apr table, which doesn't depend on $r at all
> and split it first, then do the rest, once we are happy with that one?
> the added benefit to start with it, is merging Joe's sub-tests into it.
That sounds good - I'll do that in a separate message.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] common apr/apr-ext tests
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> I've been working at reworking some of the apr
> tests so that they can also function as apr-ext
> tests, with as much common code as possible.
> I have a working set, but before getting into
> specifics, thought it'd be good to discuss some
> of the design issues first.
>
> As Stas suggested in some earlier messages,
> one could put the common tests in one package,
> and then call it from both t/apr/ and t/apr-ext/.
> So the simplest tests (eg, constants.t), would
> look like:
> ==============================================
> # file t/apr-ext/constants.t
> use lib qw(t);
> require aprlib::constants;
TestAPRlib::constants ? to avoid possible future collisions?
> So the first question I had - is there a better
> name and/or location than "t/aprlib/" to put
> in the common code?
I'd rather see t/lib and have all those packages there, to clearly
separate those from directories with tests. And adjust @INC to include
those dirs.
t/lib/TestAPRlib/*
> However, all the other tests require something
> more complex, as the corresponding t/apr/ tests
> use $r explicitly. What about the following
> model? For some test foo, one has
[...]
> I guess this could also be made simpler by, in the
> common tests, always using APR::Pool and APR::Table,
> but perhaps it would be good to test $r->pool and
> $r->notes in an httpd environment?
I think it's the best to split plan() away from the subs with tests. I
think the subs should be just ok() tests, like a few wrappers that we
have inside normal tests (e.g. the apr/pool tests has a few subs each
declares in the comment how many tests it runs.
So I propose the following plan of action. First take the simple tests
that can be decoupled from $r and have them put into a separate sub
moved into t/lib/..., leave the $r-dependent tests where they are, and
to start with run from both locations just those subs which don't
require $r.
But, don't forget that we can do Apache::RequestRec->new() and voila, we
have $r. It won't work in some cases, but may be something that will be
just right in others. Just something to consider.
Let's take one test like apr table, which doesn't depend on $r at all
and split it first, then do the rest, once we are happy with that one?
the added benefit to start with it, is merging Joe's sub-tests into it.
--
__________________________________________________________________
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