httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: More basics on the perl-framework stuff..
Date Fri, 21 Dec 2001 11:51:41 GMT
>>I was thinking that the best solution would be to encode the need for 
>>scanning a certain file in its name. e.g. foo.conf.t or foo.c.t, foo.ct 
>>(like this one the best since it won't appear in the tests stats 
>>output), so you still have one file and no need to open the files at 
>>all. The only caveat is if you decide to add the config part to an 
>>existing test you have to re-name it in cvs, plus MANIFEST file. Not 
>>sure which of the evils is less of an evil :)
> well first there is the same problem as above, if authors forget to name
> their files special.  second, having to rename files is no good.
> third, there will either be funny looking test output or we have to
> rewrite Test::Harness to rip the special part of the name out.

I was thinking some more about this issue and came to a conclusion that 
there is nothing we should add, since we have already a working solution:

The response part of the test allows you to specify 
APACHE_TEST_CONFIGURE and __DATA__, so if you have only the request part 
of the test (.t) just add an empty response part (.pm) where you can add 
the __DATA__ section that can push stuff to .conf and 
APACHE_TEST_CONFIGURE for doing things during t/TEST -config.

The only change we need is that if the file doesn't specify a handler
its corresponding <Location> won't be automatically added to .conf.
(or we have add some other indication of the the empty response part 
which serves only for configuration).

Why do I think that this is a good thing? Because the configuration that 
you want to add to .conf is relevant to the response part not the 
request part.

Stas Bekman             JAm_pH      --   Just Another mod_perl Hacker      mod_perl Guide

View raw message