Seems most of this has already been hashed out, but here are a couple of other comments.
> all my scripts ended with a simple print statement: "ALL > DONE". I ran the script, and if I saw my ALL DONE at the end, the > script was fine. If I didn't, I obviously had a problem. Conceptually this is fine, but it touches on something chromatic wrote: Any solution which requires a human being to read and think about the output beyond "It's all okay!" or "Something fell!"* is not a long-term solution. This is a critical point in testing. Having 'messy' test output is dangerous and the companies I've worked with who've tolerated this have had buggy tests, sometimes quite serious ones. TODO output, diagnostics, warnings, or just plain having stuff printed to STDOUT and STDERR are all things which clutter the output of a test suite. With cluttered output, the eyes start glazing over and mentally programmers say "yeah, yeah, I've already seen that" and when that output is indicative of bugs, they stop paying attention. As a result, printing "ALL DONE" for tests, while solving one problem, exacerbates another. I would be extremely leery of anything which increases output I HAVE to read. > Not criticizing, not claiming my method is better, just looking for > any reasons why this wouldn't work. And, JIC there's some agreement > that it _would_ work, I've already put together a patch for > Test::Most > that does it. I'm favorably inclined to introduce a feature like this. That is, at the top of your script, you put this: > > use Test::Most 'defer_plan'; > > and at the bottom of your script, you put this: > > all_done(); How easy it is for that to also allow a specified plan? all_done(23); And from another email: > The all_done() is handled by each individual test script. It should > never be called in a library. Test::Aggregate might have to perform > some magic to make sure it only gets called once, but my impression > is that Test::Aggregate is already fairly magical. I have a version here at work which is slightly less magical, but still is forced to do some monkey patching of Test::Builder. It's a bit safer than what is currently on the CPAN but it's still pretty magical. In particular, I've had to write a lot of special case code to work around Test::NoWarnings because that magically adds another test and I'm adding plan safety to this code. Any other code which has an impact on plans would be extremely problematic since the inflexibility of plans is very painful. That being said, I recommend that people *not* use Test::Aggregate unless they are backed into a corner. It works surprisingly well, but the baling wire and duct tape is clearly visible. Test::Class is a far better solution for this problem, assuming a single driver script. Cheers, Ovid -- Buy the book - http://www.oreilly.com/catalog/perlhks/ Perl and CGI - http://users.easystreet.com/ovid/cgi_course/ Personal blog - http://publius-ovidius.livejournal.com/ Tech blog - http://use.perl.org/~Ovid/journal/
