Ofer Nave wrote:

I've written a new module for CPAN called Parallel::Simple. It's my first CPAN module, and I have not yet uploaded it because I have not yet written any formal tests for it (although I use it in production currently). I've also never written any formal tests in perl at all (using the Test::* libraries).

I've skimmed the Test::* docs, including Tutorial, read various articles on perl.com, and I have the Sam Tregar book, so I'm confidant I can figure out how to use the tools. The question remains as to how to apply them. In particular, how would you design formal tests for code that forks?

Not to be facetious, but what are your requirements? What features is your code trying to deliver? Forget about testing whether your code does what you think -- test whether your code does what you intended and documented. (Plug for test-first design is that it forces you to determine your spec in a formal fashion before you write your code!) At the core, you seem to have two overarching features:

* given some arguments with code blocks, execute the arguments, and store their exit values
* execute the code in parallel


The first is easy enough to test for variations of your parameters styles, return values, code that dies, etc. As long as you get what you expect from the black box, you pass the test, whether or not it's actually forking in the background.

For the second, how do you confirm it's running in parallel? Or rather, how do you know that it's running forked? At first order, you need to find a way to get the pid back out of each of the children. Maybe use Test::Output to capture STDOUT and have each function print it's pid? If you use two functions, you should expect two lines of output each with a different pid.

Regards,
David





Reply via email to