On Wed, May 18, 2005 at 09:52:28PM -0500, Walter Goulet wrote: > The obvious way to follow this testing paradigm is to simply start and > stop servers inside each test script, but that seems wasteful as ssl > servers aren't the quickest servers to start up.
I'd first see if this approach runs acceptably quickly before getting into more complicated stuff. > It would be nice if I could start the servers before starting any tests > (or make starting the server successfully a test) then kill them after > all tests complete. > > Any advice on how to go about this problem? Maybe use 'system' to start > the servers in a seperate shell and write the PIDs of the servers to a > file so I can kill them later? Depends. Does the server contain code you're testing? If so then you're in a pickle. The server has to shut down at the end of your test suite run so it can see any code changes between test suite runs. But its difficult to tell when the last test has run AND allow users to run tests individually. What you could do is have individual tests each call a setup() and teardown() function. Normally these start and stop the server. But as an optimization you can have your test suite touch a file or set some environment variable which tells the server not to shutdown. Then at the end of the suite the file is removed/env var deleted and the server is shut down. You can put this in a t/00setup.t and t/zz_teardown.t or you can alter the test target of your module installer. The former is easier if you're using MakeMaker the later for Module::Build. If the server does not contain code you're testing, for example a simple HTTP server against which to test HTTP client code, then you can just start it and leave it running. Set it to shutdown after N minutes of inactivity. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Reality is that which, when you stop believing in it, doesn't go away. -- Phillip K. Dick
