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.

Ovid wrote:
>> However, if you use the '-s' switch to shuffle your tests 
>> and bailout is not first, then some tests will run until the 
>> BAIL_OUT is hit.  This seems to violate the principle that 
>> tests should be able to run in any order without dependencies.

Michael G Swern replied:
> It doesn't violate the principle since the tests are not 
> dependent on BAIL_OUT happening, its just a convenience.  The 
> tests should still run fine in any order, it'll just be a lot 
> noisier.

I think Ovid means it violates it in the sense that BAIL_OUT typically
stops all subsequent tests, which implies some sort of ordering. I've
certainly used it that way before, in the manner of:

01example.t - a simple test
02example.t - another simple test
03example.t - a complex test which requires Foo::Bar, BAIL_OUT if not
found
04example.t - requires Foo::Bar
05example.t - requires Foo::Bar

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.


-- 
Greg Sabino Mullane [EMAIL PROTECTED]
End Point Corporation

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to