--- chromatic <[EMAIL PROTECTED]> wrote: > > How is this simpler than 'bail on fail' or 'die on fail'? > > It doesn't conflate "output TAP results from tests" with "interpret > TAP results from tests".
Neither does "die on fail". "Die on fail" doesn't violate that in the slightest because it's the *tests* and Test::Builder which determines what TAP is output and how the tests behave. The TAP::Parser merely reads what they tell 'em. This solution was quick, easy (with the limitations imposed by Test::Builder) and more importantly, it's real, working code that is available on the CPAN. Now if I have a test suite which takes 45 minutes to run and I get a failure 3 minutes into that, it's not an *insane* idea to say "hey, let's stop the test suite and not tie up my resources for another 42 minutes". Not only do different test suites and environments potentially require different test strategies, different tester's personalities also require different test strategies. This Is Not A Bad Thing! Side note: I'm thinking that all of those 't/00-load.t' tests are excellent candidates for 'bail on fail'. The various solutions people are talking about are more akin to MVC "views". I think implementing more views would be an excellent idea and I really do hope that folks follow through on this. 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/
