silent
except for a summary.
TAP::Tests would not only allow us to have a clean way of getting to
TAP 2.0, but it would also allow us to include more standard test
functions and clean up bits of the current testing framework that we're
not happy with:
use TAP::Tests tests = 3;
ok $foo, 'foo
' caused a
problem:
Side note: I've figured out how to shoehorn the -Q switch on there.
TAP::Tests would still be very useful though.
Cheers,
Ovid
--
Buy the book -- http://www.oreilly.com/catalog/perlhks/
Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Ovid wrote:
Some of the limitations of TAPx::Parser are due to how Test::Builder
works. One thing which isn't making it into 'runtests' is the -Q
switch. I have a -q which doesn't print test failures while tests are
running, but as you can see, one of my 'stress tests' caused a problem:
--- Michael G Schwern [EMAIL PROTECTED] wrote:
TAPx-Parser $ /usr/bin/perl -Ilib bin/runtests -qm tbad/
tbad/060-aggregator..ok
tbad/badtestsFAILED tests 1, 2, 4, 5, 7, 8, 10, 11, 13,
14,
16, 17, 19, 20, 22, 23, 25, 26, 28, 29, 31, 32, 34, 35, 37, 38, 40,
41,
43, 44,
Ovid wrote:
--- Michael G Schwern [EMAIL PROTECTED] wrote:
TAPx-Parser $ /usr/bin/perl -Ilib bin/runtests -qm tbad/
tbad/060-aggregator..ok
tbad/badtestsFAILED tests 1, 2, 4, 5, 7, 8, 10, 11, 13,
14,
16, 17, 19, 20, 22, 23, 25, 26, 28, 29, 31, 32, 34, 35, 37, 38, 40,
41,
--- Michael G Schwern [EMAIL PROTECTED] wrote:
That list of FAILED tests does not come from Test::Builder. I'm
still missing something.
You are correct. I had bollixed my tests (it turns out that running
tests which run tests and then drive the results through the test
harness I'm testing is
