You are viewing a plain text version of this content. The canonical link for it is here.
Posted to test-dev@httpd.apache.org by Geoffrey Young <ge...@modperlcookbook.org> on 2004/08/05 16:59:27 UTC
Test::More server support redux
hi all...
michael schwern is very close to releasing Test::More 0.49, which is the
first version of Test::More that we can use as the server-backend for
Apache::Test.
I would like to integrate the Test::More foo into A-T as soon as 0.49 comes
out. so, if you are interested in Test::More support and have some free
tuits, I would appreciate some feedback on the work I have thus far.
the first thing to do is download the latest Test::More
http://search.cpan.org/CPAN/authors/id/M/MS/MSCHWERN/Test-Simple-0.48_02.tar.gz
which schwern said is really the release candidate for 0.49.
then, apply the attached patch and let me know how the tests turn out.
really, I know that the Apache/Test.pm patch works, so if you have test
failures it is more likely due to the test setup itself - I didn't want to
move from Apache::TestRun to Apache::TestRunPerl so I needed to set up some
of the mod_perl specific things myself. hopefully I got most of them right :)
the tests pass successfully for me for apache 1.3 and 2.0, both with and
without mod_perl installed (well, they don't run with without mod_perl but
they don't implode either ;)
anyway, as I've mentioned before, I've been using Test::More as the backend
for a while now on a corporate project and it rocks, so I'm excited to port
it over when 0.49 is official. feedback welcome.
--Geoff
Re: Test::More server support redux
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>>why this change? is there anything wrong with -Mlib?
>
>
> yes. the problem is that currently all.t does not get run properly from
> Apache-Test/. the current code adds makes @INC look like
> perl-framework/Apache-Test/Apache-Test/lib when running from the A-T directory.
I should add that there's nothing wrong with -Mlib, but that I chose
PERL5LIB because it separates paths on colons and -Mlib doesn't, which saved
me needing to store two $lib variables and add -Mlib twice. and I didn't
think it was a big deal with -T for the reasons mentioned (which I did
consider :)
--Geoff
Re: Test::More server support redux
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>>>why this change? is there anything wrong with -Mlib?
>>>
>>>
>>>
>>>yes. the problem is that currently all.t does not get run properly from
>>>Apache-Test/. the current code adds makes @INC look like
>>>perl-framework/Apache-Test/Apache-Test/lib when running from the A-T
>>>directory.
>>
>>
>>right, so the solution is to expand it to the full path as everywhere
>>else. Don't rely on relative paths.
>
>
> the problem isn't relative versus absolute paths - vars{'top_dir'} is
> already absolute. the problem is that top_dir is different when run from
> perl-framework/ versus perl-framework/Apache-Test/ - so
> perl-framework/t/php/all.t hits that code and all is well,
> perl-framework/Apache-Test/t/more/all.t hits it and can't find the proper lib.
>
> I thought there was some code I could use to resolve the issue for me (in
> the "I've moved t/" code) but I didn't see it.
Ah sorry, I've missed the Apache-Test/Apache-Test/ concat.
Still this is a run-time thingy, why can't you check at run time whether
a directory exists and pick the right one? Pushing both just in case,
doesn't sound right.
Me thinking that run_t simply wasn't adjusted to accomodate the change
of moving into t/ on the startup. See what I mean?
--
__________________________________________________________________
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
Re: Test::More server support redux
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>>> why this change? is there anything wrong with -Mlib?
>>
>>
>>
>> yes. the problem is that currently all.t does not get run properly from
>> Apache-Test/. the current code adds makes @INC look like
>> perl-framework/Apache-Test/Apache-Test/lib when running from the A-T
>> directory.
>
>
> right, so the solution is to expand it to the full path as everywhere
> else. Don't rely on relative paths.
the problem isn't relative versus absolute paths - vars{'top_dir'} is
already absolute. the problem is that top_dir is different when run from
perl-framework/ versus perl-framework/Apache-Test/ - so
perl-framework/t/php/all.t hits that code and all is well,
perl-framework/Apache-Test/t/more/all.t hits it and can't find the proper lib.
I thought there was some code I could use to resolve the issue for me (in
the "I've moved t/" code) but I didn't see it.
--Geoff
Re: Test::More server support redux
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>>+Note that I<Test::Builder> 0.18_01, available in I<Test::Simple>
>>>+version 0.48_01 on CPAN, is required to use this feature.
>>
>>
>>drop that, as 2 copies of the same thing in different places will go out
>>of sync at some point. check on the code level should be sufficient.
>>instead the error message could say where to find the required version.
>
>
> well, maybe it's not clear - colloquially most people I've talked to refer
> to Test::More. but Test::More isn't a distribution, it's part of
> Test::Simple (as is Test::Builder).
>
> anyway, I'll know more about the module versions when Test::Simple 0.49 is
> released - if all the versions of the underlying packages are correct I'll
> just require 0.49 and be done with it.
sure, all I'm saying is that move that explanation into the error
message if the version is not satisfied (eval it to trap it :)
>>>- my $lib = catfile Apache::Test::vars('top_dir'), qw(Apache-Test
>>>lib);
>>>- my $cmd = qq[$^X -Mlib="$lib" $file];
>>>+ # so we can find Apache/Test.pm from both the perl-framework
>>>+ # and Apache-Test. note that IS_APACHE_TEST_BUILD returns
>>>+ # true for the perl-framework as well
>>>+ my $lib = join ':',
>>>+ catfile(Apache::Test::vars('top_dir'), qw(Apache-Test lib)),
>>>+ catfile(Apache::Test::vars('top_dir'), 'lib');
>>>+ my $cmd = qq[PERL5LIB="$lib" $^X $file];
>>
>>
>>why this change? is there anything wrong with -Mlib?
>
>
> yes. the problem is that currently all.t does not get run properly from
> Apache-Test/. the current code adds makes @INC look like
> perl-framework/Apache-Test/Apache-Test/lib when running from the A-T directory.
right, so the solution is to expand it to the full path as everywhere
else. Don't rely on relative paths.
>>PERL5LIB will be
>>ignored under -T -- code will be broken.
>
>
> yes, but it shouldn't be a problem, since $lib is only important if A-T
> can't be found, which is presumably only when running from the
> perl-framework/ or Apache-Test/ directories. which is why I have my comment
> that IS_APACHE_TEST_BUILD is insufficient to determine whether it is a real
> A-T build or someone running from the perl-framework.
still, let's not pollute things with env vars. remember that they affect
other things indirectly. using a full path will do the trick.
>>>+
>>>+<IfModule mod_perl.c>
>>>+ <IfDefine APACHE2>
>>>+ PerlModule Apache2
>>>+ </IfDefine>
>>
>>
>>why not put the stuff below into extra.last.conf.in. Apache2 will be
>>loaded by then. It's better not to mess with Apache2 before times.
>
>
> because unless I use TestRunPerl (over TestRun) nothing mod_perl will be set
> up, including Apache2. so it's not a matter of timing, but rather if
> Apache2 is loaded at all.
ah, ok, may be add a comment then, so the question doesn't raise again
(the fact that you use TestRun).
>>>+use Apache::TestRequest 'GET_BODY_ASSERT';
>>>+print GET_BODY_ASSERT "/TestMore__testmorepm";
>>
>>
>>hmm, what are you trying to achieve with repeating two tests twice? what
>>if you don't hit the same interpreter if that's what you are after?
>
>
> the reason they are run twice (and in alternating Test.pm and Test::More
> order) is that when I first coded it there was a bug in that Test::More
> would never release itself from the tests due to some global variables.
> 0.49 addresses this with an official API for persistent environments, which
> I can now call (and is why we can't use any earlier versions).
>
> so, yes, I suppose it is an interpreter issue.
>
>
>>It's probably better to use 1 test and run the same_interprter framework?
>
>
> well, the multiple test calls are to make sure that users can intermix
> Test.pm and Test::More plans on the server, so I clearly want multiple tests
> and not just one if I'm going to mimic user activity. but I'll look into
> using same_interpreter to make sure that threaded mpms work properly as well.
I understood that. The problem is that your tests are very fragile,
since if they don't hit the same interpreter they are useless ;)
Unfortunately the same_interpreter framework works inside the same
client. I'm not sure how to extend it to work across several clients.
>>>+ 0;
>>
>>
>>What's 0? Should it be Apache::OK?
>
>
> sure.
you want it to run under mp1 and mp2, right? so this should do the trick:
BEGIN {
require mod_perl;
if ($mod_perl::VERSION >= 1.99) {
require Apache::Const;
Apache::Const->import('OK');
}
else {
require Apache::Constants;
Apache::Constants->import('OK');
}
}
...
return OK;
--
__________________________________________________________________
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
Re: Test::More server support redux
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
>> +Note that I<Test::Builder> 0.18_01, available in I<Test::Simple>
>> +version 0.48_01 on CPAN, is required to use this feature.
>
>
> drop that, as 2 copies of the same thing in different places will go out
> of sync at some point. check on the code level should be sufficient.
> instead the error message could say where to find the required version.
well, maybe it's not clear - colloquially most people I've talked to refer
to Test::More. but Test::More isn't a distribution, it's part of
Test::Simple (as is Test::Builder).
anyway, I'll know more about the module versions when Test::Simple 0.49 is
released - if all the versions of the underlying packages are correct I'll
just require 0.49 and be done with it.
>> - my $lib = catfile Apache::Test::vars('top_dir'), qw(Apache-Test
>> lib);
>> - my $cmd = qq[$^X -Mlib="$lib" $file];
>> + # so we can find Apache/Test.pm from both the perl-framework
>> + # and Apache-Test. note that IS_APACHE_TEST_BUILD returns
>> + # true for the perl-framework as well
>> + my $lib = join ':',
>> + catfile(Apache::Test::vars('top_dir'), qw(Apache-Test lib)),
>> + catfile(Apache::Test::vars('top_dir'), 'lib');
>> + my $cmd = qq[PERL5LIB="$lib" $^X $file];
>
>
> why this change? is there anything wrong with -Mlib?
yes. the problem is that currently all.t does not get run properly from
Apache-Test/. the current code adds makes @INC look like
perl-framework/Apache-Test/Apache-Test/lib when running from the A-T directory.
> PERL5LIB will be
> ignored under -T -- code will be broken.
yes, but it shouldn't be a problem, since $lib is only important if A-T
can't be found, which is presumably only when running from the
perl-framework/ or Apache-Test/ directories. which is why I have my comment
that IS_APACHE_TEST_BUILD is insufficient to determine whether it is a real
A-T build or someone running from the perl-framework.
>> +
>> +<IfModule mod_perl.c>
>> + <IfDefine APACHE2>
>> + PerlModule Apache2
>> + </IfDefine>
>
>
> why not put the stuff below into extra.last.conf.in. Apache2 will be
> loaded by then. It's better not to mess with Apache2 before times.
because unless I use TestRunPerl (over TestRun) nothing mod_perl will be set
up, including Apache2. so it's not a matter of timing, but rather if
Apache2 is loaded at all.
>> +use Apache::TestRequest 'GET_BODY_ASSERT';
>> +print GET_BODY_ASSERT "/TestMore__testmorepm";
>
>
> hmm, what are you trying to achieve with repeating two tests twice? what
> if you don't hit the same interpreter if that's what you are after?
the reason they are run twice (and in alternating Test.pm and Test::More
order) is that when I first coded it there was a bug in that Test::More
would never release itself from the tests due to some global variables.
0.49 addresses this with an official API for persistent environments, which
I can now call (and is why we can't use any earlier versions).
so, yes, I suppose it is an interpreter issue.
> It's probably better to use 1 test and run the same_interprter framework?
well, the multiple test calls are to make sure that users can intermix
Test.pm and Test::More plans on the server, so I clearly want multiple tests
and not just one if I'm going to mimic user activity. but I'll look into
using same_interpreter to make sure that threaded mpms work properly as well.
>> + 0;
>
>
> What's 0? Should it be Apache::OK?
sure.
--Geoff
Re: Test::More server support redux
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
> hi all...
>
> michael schwern is very close to releasing Test::More 0.49, which is the
> first version of Test::More that we can use as the server-backend for
> Apache::Test.
>
> I would like to integrate the Test::More foo into A-T as soon as 0.49 comes
> out. so, if you are interested in Test::More support and have some free
> tuits, I would appreciate some feedback on the work I have thus far.
>
> the first thing to do is download the latest Test::More
>
> http://search.cpan.org/CPAN/authors/id/M/MS/MSCHWERN/Test-Simple-0.48_02.tar.gz
>
> which schwern said is really the release candidate for 0.49.
>
> then, apply the attached patch and let me know how the tests turn out.
> really, I know that the Apache/Test.pm patch works, so if you have test
> failures it is more likely due to the test setup itself - I didn't want to
> move from Apache::TestRun to Apache::TestRunPerl so I needed to set up some
> of the mod_perl specific things myself. hopefully I got most of them right :)
>
> the tests pass successfully for me for apache 1.3 and 2.0, both with and
> without mod_perl installed (well, they don't run with without mod_perl but
> they don't implode either ;)
>
> anyway, as I've mentioned before, I've been using Test::More as the backend
> for a while now on a corporate project and it rocks, so I'm excited to port
> it over when 0.49 is official. feedback welcome.
No time for this now, but if it works for you go ahead with it.
> +Note that I<Test::Builder> 0.18_01, available in I<Test::Simple>
> +version 0.48_01 on CPAN, is required to use this feature.
drop that, as 2 copies of the same thing in different places will go out
of sync at some point. check on the code level should be sufficient.
instead the error message could say where to find the required version.
one day we will move to Module::Build/Module::Install and have required
vs recommended lists, so this issue will become moot for CPANPLUS users.
> +Because I<Apache:Test> was initially developed using I<Test> as
> +the framework driver, complete I<Test::More> integration is
> +considered experimental at this time - it is supported as best as
> +possible but is not guaranteed to be as stable as the default I<Test>
> +interface at this time.
>
> =head1 Apache::TestToString Class
>
> Index: lib/Apache/TestHarness.pm
> ===================================================================
> RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/lib/Apache/TestHarness.pm,v
> retrieving revision 1.18
> diff -u -r1.18 TestHarness.pm
> --- lib/Apache/TestHarness.pm 4 Mar 2004 05:51:31 -0000 1.18
> +++ lib/Apache/TestHarness.pm 5 Aug 2004 14:20:06 -0000
> @@ -63,8 +63,13 @@
> sub run_t {
> my($self, $file) = @_;
> my $ran = 0;
> - my $lib = catfile Apache::Test::vars('top_dir'), qw(Apache-Test lib);
> - my $cmd = qq[$^X -Mlib="$lib" $file];
> + # so we can find Apache/Test.pm from both the perl-framework
> + # and Apache-Test. note that IS_APACHE_TEST_BUILD returns
> + # true for the perl-framework as well
> + my $lib = join ':',
> + catfile(Apache::Test::vars('top_dir'), qw(Apache-Test lib)),
> + catfile(Apache::Test::vars('top_dir'), 'lib');
> + my $cmd = qq[PERL5LIB="$lib" $^X $file];
why this change? is there anything wrong with -Mlib? PERL5LIB will be
ignored under -T -- code will be broken.
> my $h = Symbol::gensym();
> open $h, "$cmd|" or die "open $cmd: $!";
> Index: t/conf/extra.conf.in
> ===================================================================
> RCS file: /home/cvs/httpd-test/perl-framework/Apache-Test/t/conf/extra.conf.in,v
> retrieving revision 1.3
> diff -u -r1.3 extra.conf.in
> --- t/conf/extra.conf.in 27 Jun 2004 18:38:57 -0000 1.3
> +++ t/conf/extra.conf.in 5 Aug 2004 14:20:06 -0000
> @@ -4,3 +4,31 @@
> <IfModule mod_alias.c>
> Redirect /redirect http://@ServerName@/redirected/
> </IfModule>
> +
> +<IfModule mod_perl.c>
> + <IfDefine APACHE2>
> + PerlModule Apache2
> + </IfDefine>
why not put the stuff below into extra.last.conf.in. Apache2 will be
loaded by then. It's better not to mess with Apache2 before times.
> + <Location /TestMore__testpm>
> + SetHandler perl-script
> + <IfDefine APACHE2>
> + PerlResponseHandler TestMore::testpm
> + </IfDefine>
> + <IfDefine APACHE1>
> + PerlHandler TestMore::testpm
> + </IfDefine>
> + </Location>
> +
> + <Location /TestMore__testmorepm>
> + SetHandler perl-script
> + <IfDefine APACHE2>
> + PerlResponseHandler TestMore::testmorepm
> + </IfDefine>
> + <IfDefine APACHE1>
> + PerlHandler TestMore::testmorepm
> + </IfDefine>
> + </Location>
> +</IfModule>
> +
> +
> --- /dev/null 2003-09-15 06:40:47.000000000 -0700
> +++ t/more/01testpm.t 2004-08-05 07:17:22.000000000 -0700
> @@ -0,0 +1,8 @@
> +# see the description in t/more/all.t
> +
> +use strict;
> +use warnings FATAL => qw(all);
> +
> +use Apache::TestRequest 'GET_BODY_ASSERT';
> +print GET_BODY_ASSERT "/TestMore__testpm";
> +
>
> --- /dev/null 2003-09-15 06:40:47.000000000 -0700
> +++ t/more/02testmore.t 2004-08-05 07:17:27.000000000 -0700
> @@ -0,0 +1,8 @@
> +# see the description in t/more/all.t
> +
> +use strict;
> +use warnings FATAL => qw(all);
> +
> +use Apache::TestRequest 'GET_BODY_ASSERT';
> +print GET_BODY_ASSERT "/TestMore__testmorepm";
> +
>
> --- /dev/null 2003-09-15 06:40:47.000000000 -0700
> +++ t/more/03testpm.t 2004-08-05 07:17:31.000000000 -0700
> @@ -0,0 +1,8 @@
> +# see the description in t/more/all.t
> +
> +use strict;
> +use warnings FATAL => qw(all);
> +
> +use Apache::TestRequest 'GET_BODY_ASSERT';
> +print GET_BODY_ASSERT "/TestMore__testpm";
> +
>
> --- /dev/null 2003-09-15 06:40:47.000000000 -0700
> +++ t/more/04testmore.t 2004-08-05 07:17:35.000000000 -0700
> @@ -0,0 +1,8 @@
> +# see the description in t/more/all.t
> +
> +use strict;
> +use warnings FATAL => qw(all);
> +
> +use Apache::TestRequest 'GET_BODY_ASSERT';
> +print GET_BODY_ASSERT "/TestMore__testmorepm";
hmm, what are you trying to achieve with repeating two tests twice? what
if you don't hit the same interpreter if that's what you are after? It's
probably better to use 1 test and run the same_interprter framework?
> --- /dev/null 2003-09-15 06:40:47.000000000 -0700
> +++ t/response/TestMore/testmorepm.pm 2004-08-05 06:43:16.000000000 -0700
> @@ -0,0 +1,21 @@
> +package TestMore::testmorepm;
> +
> +use strict;
> +use warnings FATAL => qw(all);
> +
> +use Test::More;
> +use Apache::Test qw(-withtestmore);
> +
> +sub handler {
> +
> + plan shift, tests => 2;
> +
> + is (1, 1, 'called Test::More::is()');
> +
> + like ('wow', qr/wow/, 'called Test::More::like()');
> +
> + 0;
What's 0? Should it be Apache::OK?
> +}
> +
> +1;
>
> --- /dev/null 2003-09-15 06:40:47.000000000 -0700
> +++ t/response/TestMore/testpm.pm 2004-08-05 06:40:14.000000000 -0700
> @@ -0,0 +1,18 @@
> +package TestMore::testpm;
> +
> +use strict;
> +use warnings FATAL => qw(all);
> +
> +use Apache::Test;
> +use Apache::TestUtil;
> +
> +sub handler {
> +
> + plan shift, tests => 1;
> +
> + ok t_cmp(1, 1, 'called Apache::Test::ok()');
> +
> + 0;
ditto
--
__________________________________________________________________
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