Re: Test::Class - comments wanted
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!
Re: Test::Class - comments wanted
On Mon, 14 Oct 2002 14:46:38 -0700, Michael G Schwern wrote: 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. 4. Running too many tests (see File::Find escaping from $topdir on Mac OS 9). [1] This thinking makes me nervous, so I'm open to someone convincing me otherwise. I'd keep it as the non-default. It's nice to be able to specify exactly N tests, with the test suite catching that. If it's optional, that's fine. I'd miss it if it were completely gone. -- c
Some upcoming changes to Test::Builder
I'm working on Test::Builder 0.48 and here's some relatively major changes I'm putting in. Some advance warning and a chance for folks to convince me otherwise. * Test::Harness will no longer be optional. Currently, the tests do not require a Test::Harness upgrade. They simply skip over anything that requries T::H 2.0. This has caused a lot of problems lately with botched and shadowed T::H installs and people installing Test::More without realizing T::H wasn't really upgraded and tests which have 'no_plan' not working. The real reason I made the T::H upgrade optional was it made it easier to test against older perls. I could just run the test suite against, for example, a clean 5.5.3 without having to dirty the installation by installing T::H 2.0. I've figured a way around this with MakeMaker hackery. A future version of Test::Harness will include a post-install check to make sure it actually got installed properly and isn't being shadowed, so it will help the problem from that end. * threads will no longer be loaded by default. Currently, Test::Builder loads threads.pm if available. It was done this way because otherwise one would have to remember to load threads before Test::More (or other T::B based module) in order for it to work properly. Unfortunately, this makes it impossible to test unthreaded code with Test::More when perl is built with threads as I recently found out while trying to test threads::shared in its disabled state. As I'm going for maximum flexibility, and loading threads.pm by default makes a whole class of tests impossible, threads.pm will no longer be loaded by default. 5.8.0's threads are giving me serious headaches. When 5.8.1 comes out I might drop support for 5.8.0's threads just so I can remove a large volume of work-around code. -- Michael G. Schwern [EMAIL PROTECTED]http://www.pobox.com/~schwern/ Perl Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One List context isn't dangerous. Misquoting Gibson is dangerous. -- Ziggy
