httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Myers <...@sumthin.nu>
Subject Re: multiple configurations
Date Mon, 14 Jan 2002 04:10:59 GMT
On Jan 14, 2002 at 11:24:41 +0800, Stas Bekman wrote:
> 
> Rick Myers wrote:
> 
> > This may sound silly, but is there an *easy* way to test
> > multiple server config's?
> > 
> > For example, I have a perl module that defines a new
> > RSRC_CONF directive that I want to test in every possible
> > way. To do that I need one server with no use of the module
> > (to validate the test, I guess), one server that uses the
> > directive in only the global area, and others for various
> > combinations of global vs. virtual use.
> > 
> > The only way I can see to make this happen is to write
> > various extra .conf.in's and remove includes from the
> > httpd.conf file as each test runs. To make it work I have to
> > HUP the server after editing httpd.conf in each test, but
> > while using -X the server just dies.
> > 
> > I managed to figure out a way around -X and keep the server
> > alive beyond the HUP, but it's a real pain. The end result
> > is overloading Apache::Test::config,
> > Apache::TestConfig::new_test_server, and
> > Apache::TestRunPerl::new_test_config -- all just to get back
> > to the point where I can finally overload
> > Apache::TestServer::start_cmd and leave out the $one.
> > 
> > Thoughts?
> 
> I think you can do it using a set of a several .pm response handlers. 
> Since the __DATA__ section is used to configure the server for the 
> handler in the same file, you could write a single handler and then 
> create a number of .pm files each having a different config section in 
> its __DATA__ section as a virtual host, so they can all co-exist in the 
> without restarting the server.

That was my original thought also, but given the number of
tests I'm looking at I don't think I want to spend the next
couple years coding it. At last count there were almost 2400 tests
spread across 7 scripts.

> Another alternative I can think of is writing one big .conf.in file with 
> <IfDefine> sections and allow t/TEST to have path-thru options to enable 
> -D flags, so without changing the configuration you could run:
> 
> t/TEST -Done; t/TEST -Dtwo; t/TEST -Dthree;

Hmm.. Now that's interesting. I don't quite follow the
path-thru options bit though. I understand passing the -D's
to the server, but wouldn't that still mean you'd have to
restart it in mid-test?

If that's what you're saying, I have to admit I like the
thought of letting the test suite do the restarting as
opposed to just crossing my fingers and hoping nothing goes
wrong with my SIGHUP. Not to mention being able to forget
about all the monkey-motion I'm doing with overloading.

Rick Myers                            rik@sumthin.nu
----------------------------------------------------
The Feynman Problem       1) Write down the problem.
Solving Algorithm         2) Think real hard.
                          3) Write down the answer.

Mime
View raw message