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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
