Greg Sabino Mullane wrote: > Michael G Shwern wrote: >> Such a bother. >> ... >> You can even get clever and pack the setup/teardown calls into >> loading the module so you have even less code per script. >> >> Now each test runs independently and cleans itself up. > > True, but at the expense of having to run the startup and cleanup code > each time, which in most of my particular cases gets very expensive. It > also violates the principle of DRY. :) It would be nice if there was > something like t/_BEGIN_.t and t/_END_.t that would always run before > and after any set of tests (even shuffled ones!) Sure, there are hacks > and workarounds, but something builtin would be nice.
You can already control the order that tests run in. Why do you need more than that? > I want a failure in 3 to stop 4 and 5 from running. For that matter, I > want a failure in 3 or 4 or 5 to prevent any of the others 2 from > running. But 1 and 2 can run irregardless of failures in 3, 4, and 5. > The ordering is a convenience to doing so, but ideally there would be > some way to interact with the testing program and do the right thing, so > that instead of BAILing out at 3, it bails out of the current test, sets > a flag, and then 4 and 5 can check for the flag and skip if it is not > set. I think you're expecting too much from the default test harness. If your project has special needs then write your own test harness. It should be dead simple now with TAPx::Parser. -- Michael Peters Developer Plus Three, LP
