"Malte S. Stretz" <[EMAIL PROTECTED]> writes:

> 1.  It has to work also if only single tests are run, so can't rely on a 
> 99_stop_spamd.t to clean up.
> 
> 2.  It would change the test semantics.  Currently each test is run on a 
> clean spamd.  If the spamd was persistent, a test could fail because of 
> some bug hidden somewhere else.  Not that finding ng these bugs was a bad 
> thing but it would make the tests a bit non-deterministic.

Here's an optimization to greatly reduce unnecessary start/stop.

After running each test, leave spamd running and store the flags and
configuration that were used to run spamd.  In the next test:

  - if the flags were changed, stop and restart spamd
  - else if the configuration was changed, kill -HUP spamd

I think it would be good, not just for performance reasons, to reuse
spamd processes when possible, because it might turn up somewhat more
complex issues.

Daniel

-- 
Daniel Quinlan
http://www.pathname.com/~quinlan/

Reply via email to