On Sun, Oct 13, 2002 at 04:01:10PM -0700, David Wheeler wrote: > On Sunday, October 13, 2002, at 10:05 AM, Tony Bowden wrote: > >> Makes it simpler for people who prefer the 'no_plan' style of > >> testing > > > >Maybe this is what I just don't get. I'm not one of those people, so I > >don't really understand why people might prefer it. Especially here > >where there's such a natural way to specify them, and you're only > >counting them per method, rather than over the entire test. > > I have to agree with Tony. I think it's important to explicitly > indicate the number of tests that a given method runs, and to be > explicit about saying when you're not sure how many tests there will > be.
The reason I went with no_plan in Test::Inline was that unlike a dedicated test script, a T::I test is cobbled together from a series of seperated blocks of tests and it's more difficult than usual to count them all and add them up. Adds another step to writing more tests. Test::Class shares that cobbled together nature, but if it has a way to specify them on a per-block basis, that will work without much trouble. OTOH, my thinking recently is that the explicit plan has become obsolescent. [1] The explicit plan protects against: 1. Your test dying. 2. Your test not printing tests to STDOUT 3. Exiting early via exit(). #1 and #2 are protected by other implicit mechanisms in Test::Builder. #3 will be protected against by overriding CORE::exit in a future version. For the negatives to the explicit plan: 1. Makes writing SKIP blocks more difficult 2. Makes writing complex, iterative/looping tests more difficult Of course, no_plan requires Test::Harness to be upgraded which has been causing some problems lately. Something I'm moving to fix by making the Test::Harness upgrade non-optional when you install Test::More. But that's an implementation issue and will eventually fade away. [1] This thinking makes me nervous, so I'm open to someone convincing me otherwise. -- Michael G. Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Here's hoping you don't become a robot!
