Customizing Test::Builder (was Re: TAP::Builder)

Ovid wrote: >> Side note: those features I really want control over in >> Test::Harness >> are the plan() and ok() methods. There's no clean way for me to do >> that. Just look at the constructor: >> >> my $Test = Test::Builder->new; >> sub new { >> my($class) = shift; >> $Test |

package Outer::Space; use Test::More tests => 9;

Ok, here's what I've decided about the changes to the way Test::Builder handles plans. None of this requires TAP or Test::Harness changes. * The restriction on requiring a plan before running a test will be lifted. use Test::More; pass(); plan tests => 2; pass()

Re: shouldn't "UNEXPECTEDLY SUCCEEDED" mean failure?

Fergal Daly wrote: > The importance of the test has not changed. Only the worth of the > failure report has changed. > > This could be solved by having another classification of test, the > "not my fault" test used as follows > > BLAME: { > $foo_broken = test_Foo(); # might just be a version ch

Re: Why not run a test without a plan?

A. Pagaltzis wrote: > * Michael G Schwern <[EMAIL PROTECTED]> [2007-12-05 15:00]: >> I'm going to keep drilling through the BS until I either hit >> bottom or punch through. > > Yeah, we’re all spouting bullshit. Gee, some tone you’re setting. Sorry, I forgot the :) That I'm pushing so hard to g

Re: Why not run a test without a plan?

Eric Wilhelm wrote: >> Give me something concrete, not just "it's better". I'm going to >> keep drilling through the BS until I either hit bottom or punch >> through. > > It allows you to apply the policy "all tests have a plan" at the test > level. Yes, policy often sounds like BS. > > By his

Re: TODO -> MAYBE tests?

Eric Wilhelm wrote: > # from Michael G Schwern > # on Wednesday 05 December 2007 05:47: > >>> Perhaps a general sort of MAYBE namespace in TAP would be a nice >>> addition. >> Is this a joke? I hope it's a joke. > > Do I look like I'm joking? >:-| > > As it is, we're talking about detecting/r

Re: shouldn't "UNEXPECTEDLY SUCCEEDED" mean failure?

On 05/12/2007, Michael G Schwern <[EMAIL PROTECTED]> wrote: > I'm going to sum up this reply, because it got long but kept on the same > themes. > > * TODO tests provide you with information about what tests the author decided > to ignore. > ** Commented out tests provide you with NO information

Re: Why not run a test without a plan?

* Eric Wilhelm <[EMAIL PROTECTED]> [2007-12-05 18:20]: > but maybe a Test::MustPlan (complete with syntactic-sugar for > the annoying BEGIN thing.) That would be a good option. That way Test::More wouldn’t be loaded down with ever more bloat, and whoever has a need to ensure plan-first TAP streams

Re: Why not run a test without a plan?

# from Michael G Schwern # on Wednesday 05 December 2007 05:55: > Give me something concrete, not just "it's better".  I'm going to > keep drilling through the BS until I either hit bottom or punch > through. It allows you to apply the policy "all tests have a plan" at the test level. Yes, poli

Re: TODO -> MAYBE tests?

# from Michael G Schwern # on Wednesday 05 December 2007 05:47: >> Perhaps a general sort of MAYBE namespace in TAP would be a nice >> addition. > >Is this a joke?  I hope it's a joke. Do I look like I'm joking? >:-| As it is, we're talking about detecting/reporting a 3rd thing, which only

Re: shouldn't "UNEXPECTEDLY SUCCEEDED" mean failure?

On Tue, Dec 04, 2007 at 08:25:10PM -0800, Michael G Schwern wrote: > Fergal Daly wrote: > > You have no idea what version of Foo they're using > > Well, you do with version dependency declarations so you control the range. > New versions are, of course, open to breakage but at some point you hav

Re: Why not run a test without a plan?

* Michael G Schwern <[EMAIL PROTECTED]> [2007-12-05 15:00]: > I'm going to keep drilling through the BS until I either hit > bottom or punch through. Yeah, we’re all spouting bullshit. Gee, some tone you’re setting. > About all that's different when the plan is at the end is the > TAP reader does

Re: Why not run a test without a plan?

A. Pagaltzis wrote: > * Michael G Schwern <[EMAIL PROTECTED]> [2007-12-05 04:30]: >> Why do they care if the plan is output at the beginning or end? >> How does this stricture improve the quality of the test? > > It improves the resulting TAP stream, if not the test itself. What's "improved" abou

Re: TODO -> MAYBE tests?

Eric Wilhelm wrote: > Since we're on the subject of CPAN::Reporter, TAP::Harness, Test::More, > and TODO wrt failure vs. no-noise vs. report-back vs. await-dependency > and the binaryism of failure and etc... > > Perhaps a general sort of MAYBE namespace in TAP would be a nice > addition. Is t

Re: UNKNOWN despite only failing tests -- how come?

On 4 Dec 2007, at 23:37, Michael G Schwern wrote: Test::Harness bug where it concludes "NOTESTS" if it sees no test output, as is the case when every test dies. I'll see about fixing it. Is done. -- Andy Armstrong, Hexten

Re: Why not run a test without a plan?

* Michael G Schwern <[EMAIL PROTECTED]> [2007-12-05 04:30]: > Why do they care if the plan is output at the beginning or end? > How does this stricture improve the quality of the test? It improves the resulting TAP stream, if not the test itself. But maybe it’s not necessary to impose this strict

Re: UNKNOWN despite only failing tests -- how come?

On 4 Dec 2007, at 20:24, Andreas J. Koenig wrote: Bug in CPAN::Reporter and/or Test::Harness and/or CPAN.pm? http://www.nntp.perl.org/group/perl.cpan.testers/796974 http://www.nntp.perl.org/group/perl.cpan.testers/825449 All tests fail but Test::Harness reports NOTESTS and CPAN::Reporter conc

Re: UNKNOWN despite only failing tests -- how come?

On 4 Dec 2007, at 20:24, Andreas J. Koenig wrote: Bug in CPAN::Reporter and/or Test::Harness and/or CPAN.pm? http://www.nntp.perl.org/group/perl.cpan.testers/796974 http://www.nntp.perl.org/group/perl.cpan.testers/825449 All tests fail but Test::Harness reports NOTESTS and CPAN::Reporter con

Re: Fixing Test::Class (was: Why not run a test without a plan?)

On 5 Dec 2007, at 12:13, A. Pagaltzis wrote: * Adrian Howard <[EMAIL PROTECTED]> [2007-12-05 10:45]: There are design mistakes that I regret. Only some of them can be fixed without breaking backwards compatibility. Maybe time to put Test::Class on ice and fork an incompatible successor? It

Fixing Test::Class (was: Why not run a test without a plan?)

* Adrian Howard <[EMAIL PROTECTED]> [2007-12-05 10:45]: > There are design mistakes that I regret. Only some of them can > be fixed without breaking backwards compatibility. Maybe time to put Test::Class on ice and fork an incompatible successor? Regards, -- Aristotle Pagaltzis //

Re: Why not run a test without a plan?

On 4 Dec 2007, at 06:52, Michael G Schwern wrote: Eric Wilhelm wrote: # from David Golden # on Monday 03 December 2007 19:55: With some sugar, that could actually be quite handy for something like test blocks. E.g.: { plan add => 2; ok( 1, "wibble" ); ok(1, "wobble" ); } or maybe

Re: shouldn't "UNEXPECTEDLY SUCCEEDED" mean failure?

On Tue, Dec 04, 2007 at 04:05:07PM -0800, Michael G Schwern wrote: I've written a couple of replies to this thread with similar content, but not sent them for one reason or another. Perhaps I can be more succinct here. > Then there are folks who embrace the whole test first thing and write out l

Re: Why not run a test without a plan?

On 5 Dec 2007, at 01:24, Chris Dolan wrote: [snip] Are you proposing that Test::Class go in core? I second the motion! :-) I'm not! It shouldn't be there. There are design mistakes that I regret. Only some of them can be fixed without breaking backwards compatibility. Not something that

Re: plan 'until done'

# from Michael G Schwern # on Tuesday 04 December 2007 19:25: >Honestly all that's really holding that up is a good name for the plan > style and "I'm done testing" terminator.  Nothing has really lept out > at me yet. Maybe something as straight forward as... > >plan 'until_done'; > >

TODO -> MAYBE tests?

Since we're on the subject of CPAN::Reporter, TAP::Harness, Test::More, and TODO wrt failure vs. no-noise vs. report-back vs. await-dependency and the binaryism of failure and etc... Perhaps a general sort of MAYBE namespace in TAP would be a nice addition. The MAYBE block has a key associated