httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: Test::More server support redux
Date Thu, 05 Aug 2004 18:44:23 GMT
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
>>>-    my $cmd = qq[$^X -Mlib="$lib" $file];
>>>+    # so we can find Apache/ 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 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 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
> 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;
       else {
           require Apache::Constants;

   return OK;

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

View raw message