httpd-test-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: [RFC] running tests after the server stops
Date Thu, 18 Sep 2003 20:06:30 GMT
Geoffrey Young wrote:
> hi all...
> I'm thinking about implementing a mechansim that allows you to run 
> certain tests after the server shuts down.  the rationale behind this is 
> some work I'm doing on Devel::Profiler::Apache - the profiler generates 
> statistics when the children die off, so I need to either kill the 
> children or shut down the server to have some data to test.
> now, killing off the children is easy in 1.0 with child_terminate(), but 
> that isn't portable to 2.0 from what I can tell.
> I have wanted an API for restarting the server midstrean for a while 
> now, mainly to test per-server cleanup logic.  for that I currently use
> skip ($Apache::TestConfig::WIN32, kill HUP => 
> Apache::TestServer->new->pid);
> and that would seem to work as well here, but again with (different) 
> portability.
> however, what I really want is only one child, which would generate only 
> one  file when the server is shutdown.  then I want to be able to use 
> that file in additional tests.
> after poking around, I think I can hack together a few different options 
> to support this:
>   - a new command-line option, poststop=foo.t, which would specify tests 
> to add after the server is shutdown.
>   - treat a directory, t/poststop, as special, feeding the tests in 
> there directly to the test harness.
> or perhaps something else that somebody here can come up with :)
> I can't help but feel there would be other uses for this, but maybe I'm 
> wrong.

There are other uses for it already. We have t/apr-ext tests which require no 
running server at all. a magic directory sounds good to me. I'd even suggest 
having two of them - one for pre-start and one for post-stop. e.g.:


The only issue is with Test::Harness, we will need to somehow feed tests to it 
so it'll take them all as one bunch, while we have to run first t/pre-start/ 
test, followed by normal tests, followed by t/post-stop/ tests.

though I don't see how does it help you with restart-in-the middle. again we 
could have a magic directory which will force a server restart when it hits 
it, though I'm not sure whether we want it to restart for each test in that 
t/restart/ dir, or just once. However I think that making the client side 
doing the restart is the best option, provided that we provide a portable 
implementation for it.

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

View raw message