httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: Perl test framework, TestConfig, and debugging A::T
Date Fri, 16 Jan 2004 00:24:41 GMT
Stas Bekman wrote:
> William McKee wrote:
> 
>> On Wed, Jan 14, 2004 at 08:41:01PM -0800, Stas Bekman wrote:
>>
>>> Cool, now I get the thing running.
>>
>>
>>
>> Great. Are you getting any failures? Please read my notes in
>> testnotes.txt.
> 
> 
> Yes. I will look at the failures soonish.

I don't have apache 1.3 with ssl so I can't test it. And it doesn't quite work 
with apache/mp 2.0 because you have hardcoded mp1 API. Please see the porting 
doc: http://perl.apache.org/docs/2.0/user/porting/porting.html
http://perl.apache.org/docs/2.0/user/porting/porting.html#Making_Code_Conditional_on_Running_mod_perl_Version

For example you have a problem with constants, so under mp2 I get:
/home/stas/httpd/prefork/bin/httpd: relocation error: 
/home/stas/perl/5.8.3-ithread/lib/site_perl/5.8.3/i686-linux-thread-multi/auto/Apache/Constants/Constants.so:

undefined symbol: perl_require_module
and it shouldn't use that module.


Also you may want to adopt the convention we use for other test suites, where 
the response part of the test resides under t/response. So you usually don't 
test the module as is, but you create a response handler that tests it. But it 
doesn't have to be that way of course.

Now to your issues:

 >  - APACHE_TEST_LIVE_DEV=1 environment
 > I have written a test in 02_livedev.t which tests this setting and
 > checks that the first directory in @INC does not contain 'blib'. This
 > probably isn't a safe test for distribution due to the possibility of
 > blib being in someone's path. However, I think it is sufficient for
 > debugging purposes. This test fails on my system.

this is because you are testing in the "wrong" place. APACHE_TEST_LIVE_DEV 
affects the server, not the client. It adds 'lib' in modperl_inc.pl which 
affects the server. You need to write a response part of the test like we do 
in all other test suites and test it there.

I guess we could make the autogenerated t/TEST include that as well, the 
problem is that if you include any other libs, they will come before it in @INC.

 >  - Using two servers (one plain and one SSL)
 >
 > 	1. Getting hostport doesn't work when starting server for
 > 	   repetitive tests. Tests 3-5 will fail using the following
 > 	   sequence of commands:
 > 	t/TEST -start
 > 	t/TEST -run-tests t/03_hostport.t
 >
 > 	2. Once hostport is obtained for the second server, calls to
 > 	   '/page.html'
 > fail. I may simply be abusing the system in my ignorance. Test #5 in
 > 03_hostport.t fails for me whether you start the server first as above
 > or just run make test.

this test fails long before it gets to 3:

Use of uninitialized value in concatenation (.) or string at 03_hostport.t 
line 32.

hostport is not there. That looks like some sort of config bug. I'll look into it.


 > * The Apache::RequestRec and Apache::Const modules which are
 > shown in the sample code for Apache::Amazing are part of modper2 (not
 > sure about Apache::RequestIO, I didn't see it in the mod_perl-1.99_11
 > release).  Trying to compile a module with these results in errors
 > when running under mp1.  It'd be helpful to mention this fact for
 > those of us new to all of the Apache::* hierarchy. If they are part of
 > mp2, will not having them cause any of the problems I am experiencing
 > above since I run in mp1 (1.29 to be exact)?

You are correct. I'll add a note that this example uses mp2 API.

 > Notes:
 >  - PerlResponseHandler is a modperl2 directive; a note should be made
 >    to use PerlHandler in mp1. I've modifed the docs and will send a
 >    patch.

good.

 >  - trying to have multiple developers run TEST on the same server does
 >    not automatically invoke port select which ends up causing the
 >    second test
 > server to die with the following error:
 > 	!!! port 8529 is in use, cannot determine server pid to
 > 	shutdown
 > I modified TEST to add -port select to the list of arguments unless
 > -port was specifically set

Yes, I saw that. I think it's a bad idea, since it'll reconfigure the server 
every time you run the tests. Usually developers write scripts to test things, 
so they can explicitly add -port select if they want to. At least that's what 
I do with my tests.

__________________________________________________________________
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


Mime
View raw message