Re: Comment about BAIL_OUT

2007-01-06 Thread Michael G Schwern
Adam Kennedy wrote: > Personally, I've always wanted a per-file bail_out as well, that can > just abort the current test script, rather than the entire testing process. > > Schwern? :) die.

Re: Comment about BAIL_OUT

2007-01-06 Thread Michael G Schwern
Adam Kennedy wrote: > Lately I find myself cheating a bit on the test naming as well, by just > calling the testing package t::lib::Test. > > That saves me one entire line :) Relying on . being in @INC makes my feet itch.

Re: First try at sample test output.

2007-01-06 Thread Ovid
--- Adam Kennedy <[EMAIL PROTECTED]> wrote: > Ovid wrote: > > tbad/longtestfilenameFailed 2/10 tests > > (less 1 skipped test: 7 okay) > > (1 test unexpectedly succeeded) > > Is that last lines for a TODO? Because it just gave me a brief WTF > moment. > > Might be better for

Re: First try at sample test output.

2007-01-06 Thread Adam Kennedy
Ovid wrote: tbad/longtestfilenameFailed 2/10 tests (less 1 skipped test: 7 okay) (1 test unexpectedly succeeded) Is that last lines for a TODO? Because it just gave me a brief WTF moment. Might be better for clarity to use (1 TODO test unexpectedly succeeded) Adam K

Re: Comment about BAIL_OUT

2007-01-06 Thread Adam Kennedy
Michael G Schwern wrote: Ovid wrote: However, if you use the '-s' switch to shuffle your tests and bailout is not first, then some tests will run until the BAIL_OUT is hit. This seems to violate the principle that tests should be able to run in any order without dependencies. It doesn't viola

Re: Comment about BAIL_OUT

2007-01-06 Thread Adam Kennedy
What I did instead is moved all the setup and teardown stuff into simple functions, plopped them into modules in t/lib/ and had each test do: use lib 't/lib'; use MakeMaker::Test; setup_foo(); END { teardown_foo(); } You can even get clever and pack the setup/te

Re: Reporting 'missing' tests as failed in Test::Harness

2007-01-06 Thread Michael G Schwern
Ovid wrote: > Summary: if your TAP suddenly jumps from test #2 to test #29, > Test::Harness reports that tests #3 through #28 have 'failed'. > > TAPx::Harness does not report them as failures, but as parse errors > (because it's bad TAP). Is a 'parse error' a reasonable compromise? Technicall

Re: Thoughts about test harness summary

2007-01-06 Thread demerphq
On 1/6/07, A. Pagaltzis <[EMAIL PROTECTED]> wrote: * Ovid <[EMAIL PROTECTED]> [2007-01-05 20:15]: > How about this instead? > > -- > > Failed Test | Total | Fail | List of Failed | TODO Passed > +---+--++ > t/bar.t | 13| 4|

TAPx::Parser 0.50_01 on its way to the CPAN

2007-01-06 Thread Ovid
Now you can all find out if this was a colossal mistake or not. Cheers, Ovid 0.50_01 06 January 2007 - Added a new example which shows to how test Perl, Ruby, and URLs all at the same time using 'execrc' files. - Fixed the diagnostic format mangling bug. - We no longer override

Re: Comment about BAIL_OUT

2007-01-06 Thread A. Pagaltzis
* Eric Wilhelm <[EMAIL PROTECTED]> [2007-01-05 06:25]: > # from Greg Sabino Mullane > # on Thursday 04 January 2007 07:39 pm: > > > [1] I've never had a need for random tests myself. The only > > reason I break mine apart is to isolate testing various > > sub-systems, but I almost always end up ha

Re: Thoughts about test harness summary

2007-01-06 Thread A. Pagaltzis
* Ovid <[EMAIL PROTECTED]> [2007-01-05 20:15]: > How about this instead? > > -- > > Failed Test | Total | Fail | List of Failed | TODO Passed > +---+--++ > t/bar.t | 13| 4|2, 6-8 |3-4 > +---+

Reporting 'missing' tests as failed in Test::Harness

2007-01-06 Thread Ovid
Summary: if your TAP suddenly jumps from test #2 to test #29, Test::Harness reports that tests #3 through #28 have 'failed'. TAPx::Harness does not report them as failures, but as parse errors (because it's bad TAP). Is a 'parse error' a reasonable compromise? More information below, if you'r