A while ago, there was a debate on Perl-QA as to whether or not one must have test programs run in separate processes. What a few people ignored is:
There are pros and cons to each approach.
Run all tests in separate processes and you can know that your tests are focusing on exactly what you want to test. Run them in the same process and you can catch strange state issues. Sometimes those are in the tests, but sometimes they are in the code. Both approaches offer benefits and drawbacks.
Today's navel-gazing exercise involves being able to have a test stop when a failure occurs or optionally bailing out of the test suite when a failure occurs. For example, right now I have one test program whose 4,039 tests take over six minutes to run (yeah, it sucks, but hey, it happens). Since I'm using Test::Most, I just add a 'die' to the import list and the test program halts at the first failure. This failure happens about 38 seconds into the run and then I can see what causes the failure and rerun it with a subset of its data and recreate the error faster. This makes debugging much easier than being hunched over the keyboard waiting to hit ctrl-C if I see a failure. Or maybe I should just pipe everything through less and manually page through those results, eh? (Because this is programming and we want to increase manual involvement?)
Or I could just tell the damned tests to stop when a failure is encountered. Simple, eh?
The debate, however, has ungracefully broken down into all sorts of positions, the two most prominent which seem to be:
You know, while I advocated the second position, I know that each approach has strengths or weaknesses. Unfortunately, somehow the "harness should stop the tests" camp has become entrenched in their position and are arguing strongly for it, even going so far as to hint that their's is the "one true way." While I think their position has a lot of merit, I'm distressed at the dogmatism surrounding the topic.
Meanwhile, Test::Most does what it says on the tin.