On Thu, 2007-01-04 at 13:34 -0800, Ovid wrote: > I guess the reason I have never used BAIL_OUT is because if I have a > bunch of tests failing, they fail quickly and I don't have to wait for > them :) I suppose it's not that big of a deal, but I noticed it this > evening and thought I would toss it out there in case anyone has any > comments.
I use BAIL_OUT a lot, and find it quite useful. I've found that I have three main uses for it: 1) The reason given in the docs: if a database connection cannot be made at the top of the test, then there is no sense in going on, as the rest of the tests in that file, as well as all the other subsequent[1] tests, will all need a database connection for proper testing. 2) To stop the tests at the exact moment of failure, to ease debugging by leaving things in the broken state. 3) To simply bail out early, as a kind of die-on-any-error mechanism. Some of my test suites take a relatively long time (minutes) to complete, and I don't want to wait for them if a fail a test. I've had to do some ugly hacks to accomplish #2 and #3 automagically in my testing code. A built-in way to say "BAIL_OUT" on any error would sure be nice, as would some more control such as "BAIL_OUT_OF_THIS_TEST_ONLY" or "call this usercode upon a failed test and let me decide if I want to do something about it" [1] I've never had a need for random tests myself. The only reason I break mine apart is to isolate testing various sub-systems, but I almost always end up having some dependencies put into an early "00" file. I also tend to a have a final "99" cleanup file. While I could in theory have each file be independent, in practice it's a lot of duplicated code and a lot of time overhead, so it's either the 00-99 or (as I sometimes have done) one giant testing file. -- Greg Sabino Mullane [EMAIL PROTECTED] [EMAIL PROTECTED] End Point Corporation
signature.asc
Description: This is a digitally signed message part
