--- 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 testin
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,
--- 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,
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:
>
t; running, but as you can see, one of my 'stress tests' 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/
given up on the thought of having tests completely 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
