Re: [mp2] additional apr-ext tests

[Stas Bekman]

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:[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]