Re: done_testing() and test counts

Andy Lester wrote: > > On Jun 9, 2009, at 2:57 PM, Michael G Schwern wrote: > >>> use Test::More tests => 14; >>> ok( 1 ); >>> done_testing(); >> >> You would try that. :P > > > It's not that I tried it, it's that I did

Re: done_testing() and test counts

On Jun 9, 2009, at 2:57 PM, Michael G Schwern wrote: use Test::More tests => 14; ok( 1 ); done_testing(); You would try that. :P It's not that I tried it, it's that I didn't know what would happen if I did both together, because it wasn't clear to me up

Re: done_testing() and test counts

Andy Lester wrote: > I'm so glad for done_testing(). I don't like no_plan, but > done_testing() makes it better. > > I was surprised/confused to see this behavior: > > $ cat foo.t > use Test::More tests => 14; > ok( 1 ); > done_testing(); You wo

done_testing() and test counts

I'm so glad for done_testing(). I don't like no_plan, but done_testing() makes it better. I was surprised/confused to see this behavior: $ cat foo.t use Test::More tests => 14; ok( 1 ); done_testing(); $ prove -v foo.t [13:55:39] foo.t .. 1..14 ok 1 not ok 2 - planned

Re: [ANNOUNCE] Test::More 0.87_01 (with done_testing())

Evgeny wrote: > Super! Well done! > > Makes me feel all warm inside. > > Would kiss you if you were near here somewhere! :) I'm kind of glad I'm not, but thank you all the same. -- 24. Must not tell any officer that I am smarter than they are, especially if it's true. -- The 213 Thing

Re: [ANNOUNCE] Test::More 0.87_01 (with done_testing())

eneral it's less restrictive, you can now run > tests without first having declared a plan. > > This enables the long called for new feature of done_testing().  It's a safer > replacement for no_plan.  Looks like this: > >    use Test::More;  # look ma, no plan! > >

[ANNOUNCE] Test::More 0.87_01 (with done_testing())

Just pushed out a new alpha of Test::More. There's a bunch of new features having to do with the plan. In general it's less restrictive, you can now run tests without first having declared a plan. This enables the long called for new feature of done_testing(). It's a safer

Re: done_testing()

On Feb 23, 2009, at 1:39 AM, Aristotle Pagaltzis wrote: Or differently, to RSS? It may well be that we’ll need to break backcompat over this issue, and if so, OK, but “I don’t care about backcompat” is no way to go about designing a format that succeeds widely. Hence my suggestion for a depre

Re: done_testing()

* David E. Wheeler [2009-02-22 07:20]: > I care less and less about backwards compatibility every day. This is a format spec, not code. Guess what happened to XML 1.1? To XHTML2? Or differently, to RSS? It may well be that we’ll need to break backcompat over this issue, and if so, OK, but “I d

Re: done_testing()

On Feb 22, 2009, at 3:45 PM, Michael G Schwern wrote: I think that second one has value. Agreed, but that's what a deprecation cycle is for. TAP currently has no deprecation cycle. That's what I introduced earlier. http://www.ietf.org/mail-archive/web/tap/current/msg00411.html Good! D

Re: done_testing()

David E. Wheeler wrote: > On Feb 21, 2009, at 10:54 PM, Michael G Schwern wrote: > >> There is Perl 5 style backwards compatibility where you never, ever break >> anything for years and years and years and even for code that you're >> not sure >> even exists. That's what chromatic is on about. >>

Re: done_testing()

On Feb 21, 2009, at 10:54 PM, Michael G Schwern wrote: There is Perl 5 style backwards compatibility where you never, ever break anything for years and years and years and even for code that you're not sure even exists. That's what chromatic is on about. And then there's backwards compatib

Re: done_testing()

David E. Wheeler wrote: > On Feb 21, 2009, at 5:44 PM, Michael G Schwern wrote: > >>> Yeah, I'm suggesting this more for a new version of TAP. >> >> It won't work because it's not backwards compatible. > > I care less and less about backwards compatibility every day. Also, > chromatic. There is

Re: done_testing()

On Feb 21, 2009, at 5:44 PM, Michael G Schwern wrote: Yeah, I'm suggesting this more for a new version of TAP. It won't work because it's not backwards compatible. I care less and less about backwards compatibility every day. Also, chromatic. Technically "ok 1.1" should be read as an unn

Re: done_testing()

David E. Wheeler wrote: > On Feb 21, 2009, at 11:35 AM, Michael G Schwern wrote: > >> David E. Wheeler wrote: >>> Dot notation? >>> >>> ok 1.1 >>> ok 1.2 >>> ok 2.1 >>> 1..2 >> >> If you don't want any existing TAP parser to be able to read it and delay >> release until they do, sure! >> >> I am t

Re: done_testing()

On Feb 21, 2009, at 11:35 AM, Michael G Schwern wrote: David E. Wheeler wrote: Dot notation? ok 1.1 ok 1.2 ok 2.1 1..2 If you don't want any existing TAP parser to be able to read it and delay release until they do, sure! I am totally not waiting for TAP to work out sub-plan syntax. Ye

Re: done_testing()

David E. Wheeler wrote: > Dot notation? > > ok 1.1 > ok 1.2 > ok 2.1 > 1..2 If you don't want any existing TAP parser to be able to read it and delay release until they do, sure! I am totally not waiting for TAP to work out sub-plan syntax. -- 185. My name is not a killing word. -- Th

Re: done_testing()

Aristotle Pagaltzis wrote: > * Michael G Schwern [2009-02-20 23:35]: >> And we come back to the beginning: it's all going to be ad hoc >> anyway until TAP formalizes it. Fine for eyeballing. If someone >> wants to scrape the information out they can do it from the >> description (with the usual ca

Re: done_testing()

* Michael G Schwern [2009-02-20 23:35]: > And we come back to the beginning: it's all going to be ad hoc > anyway until TAP formalizes it. Fine for eyeballing. If someone > wants to scrape the information out they can do it from the > description (with the usual caveats about scraping). What I am

Re: done_testing()

're arguing about two different things. Or we're arguing about a plan that was already rejected. Or it's gotten very meta and we're arguing about concepts. I plan on doing this: use Test::More; plan( add => 1 ); pass("First test"); plan( add =&g

Re: done_testing()

* Michael G Schwern [2009-02-19 21:15]: > As TAP has no formal means to express that, and I'm not waiting > for a TAP extension, any TAP reader will need extra logic to > figure that out. So worrying about that seems moot. If it takes a lot longer and TB offers subplans in the meantime, people wi

Re: done_testing()

David E. Wheeler wrote: > On Feb 19, 2009, at 12:12 PM, Michael G Schwern wrote: > >>> I’m not talking about pass/fail, I’m talking about finding out >>> about subplans, from the consumer end. >> >> As TAP has no formal means to express that, and I'm not waiting for a TAP >> extension, any TAP rea

Re: done_testing()

On Feb 19, 2009, at 12:12 PM, Michael G Schwern wrote: I’m not talking about pass/fail, I’m talking about finding out about subplans, from the consumer end. As TAP has no formal means to express that, and I'm not waiting for a TAP extension, any TAP reader will need extra logic to figure tha

Re: done_testing()

Aristotle Pagaltzis wrote: > * Michael G Schwern [2009-02-19 08:40]: >> it doesn't require any extra TAP reader logic to determine pass >> or fail. > > I’m not talking about pass/fail, I’m talking about finding out > about subplans, from the consumer end. As TAP has no formal means to express th

Re: done_testing()

* Michael G Schwern [2009-02-19 08:40]: > it doesn't require any extra TAP reader logic to determine pass > or fail. I’m not talking about pass/fail, I’m talking about finding out about subplans, from the consumer end. Regards, -- Aristotle Pagaltzis //

Re: done_testing()

Aristotle Pagaltzis wrote: >> If you're referring to having two tests with the same number, >> that's perfectly valid TAP which will cause the suite to fail. >> Test::Builder should support it whether we use it for sub-plans >> or not. > > I agree with that. Let me try again: > > I’m saying that

Re: done_testing()

* Michael G Schwern [2009-02-19 06:35]: > Aristotle Pagaltzis wrote: > > But injecting artificial test results seems like a fairly big > > modification to the format’s semantics to me, and I’m not > > comfortable with the idea of doing that for no greater reason > > than that the existing codebase

Re: done_testing()

il unhappy with > the idea, but at least that leads to less variability in the > output, reducing the amount of cleverness required to correctly > interpret the resulting streams. So something like this? use Test::More; plan add => 2; pass("first"); plan add => 2; p

Re: done_testing()

On Feb 18, 2009, at 3:57 PM, Aristotle Pagaltzis wrote: Shouldn’t this be fixed? Sure, but how? I don’t know. But injecting artificial test results seems like a fairly big modification to the format’s semantics to me, and I’m not comfortable with the idea of doing that for no greater reason

Re: done_testing()

* Michael G Schwern [2009-02-18 22:45]: > Aristotle Pagaltzis wrote: > > * Michael G Schwern [2009-02-18 21:55]: > >> One of the issues with that approach is Test::Builder's > >> history can't store test #2 twice. So history is lost. > > > > Shouldn’t this be fixed? > > Sure, but how? I don’t kn

Re: done_testing()

Aristotle Pagaltzis wrote: > * Michael G Schwern [2009-02-18 21:55]: >> One of the issues with that approach is Test::Builder's history >> can't store test #2 twice. So history is lost. > > Shouldn’t this be fixed? Sure, but how? Internally, fine, it can be stored using a list of lists. But th

Re: done_testing()

* Michael G Schwern [2009-02-18 21:55]: > One of the issues with that approach is Test::Builder's history > can't store test #2 twice. So history is lost. Shouldn’t this be fixed? Regards, -- Aristotle Pagaltzis //

Re: done_testing()

s, all tests should pass, but the test suite itself should fail, > just as happens now if you have the wrong number of tests. Not sure how > you'd show that, though. Ok, makes sense. Now riddle me this, Batman: use Test::More; plan add => 1; pass("first"); pass("sec

Re: done_testing()

* David E. Wheeler [2009-02-06 04:05]: > On Feb 5, 2009, at 6:23 PM, Michael G Schwern wrote: >> Or would that be 1..4? Having an overall plan violation on >> top of the plan addition failure seems a bit much, because the >> number of tests run was correct (until we added one of our >> own). > >

Re: done_testing()

and Test::More for it, but >> for the moment this will work: >> >> use Test::More; >> >> my $tests = 2; >> pass; >> pass; >> >> $tests += 1; >> pass; >> >> done_testing($tests); > > Just a side note: this

Re: done_testing()

e Test::More; > > my $tests = 2; > pass; > pass; > > $tests += 1; > pass; > > done_testing($tests); Just a side note: this has always been possible, as I've seen people do the following: my $tests; use Test::More tests => $te

Re: done_testing()

On Feb 5, 2009, at 6:23 PM, Michael G Schwern wrote: # Planning 2 more tests at foo.t line 3. ok 1 - First test not ok 2 - 2 tests were planned but only 1 was run # Failed test "2 tests were planned but only 1 was run" # at foo.t line 6. # Planning 1 more test at foo.t line 6. ok 3 - Seco

Re: done_testing()

David E. Wheeler wrote: > On Feb 5, 2009, at 12:34 PM, Michael G Schwern wrote: > >> Though we don't have incremental TAP plans, Test::Builder can check that >> you've run all the tests you said you'd run before you add more. Thus... >> >> use Test::More; >> >> plan add => 2; >> pass; >> >> p

Re: done_testing()

On Feb 5, 2009, at 12:34 PM, Michael G Schwern wrote: Though we don't have incremental TAP plans, Test::Builder can check that you've run all the tests you said you'd run before you add more. Thus... use Test::More; plan add => 2; pass; plan add => 1; pass; # failure pass

Re: done_testing()

k(...); > if($ENV{RUN_REALLY_SLOW_TESTS}) { > add_plan(2); > ok(...); > ok(...); > } > done_testing(); Test::NoWarnings, which has to add a test without you knowing, would find that advantageous. I also allowed this: use Test::More 'no_plan'; pass(); pass();

Re: done_testing()

Gabor Szabo wrote: > BTW what about > > use Test::More; > pass; > pass; > # done_testing() # not being called at all. > > Is this a failure now as there was no plan, not even a no_plan ? It's a failure by virtue of there being no TAP plan. I didn't feel it w

Re: done_testing()

; ok(...); } done_testing(); -- David Cantrell | top google result for "internet beard fetish club" You don't need to spam good porn

Re: [test-more-users] Re: done_testing()

- Original Message > From: Gaurav Vaidya > I just made a branch of Test::Builder which does this. You can see the > expected > behaviour in the tests at: > > http://github.com/gaurav/test-more/tree/incremental-planning/t/incremental_planning/ > (or http://tinyurl.com/ad8mb4)

Re: done_testing()

::More; > > plan(3); > pass; > pass; > pass; > plan(2) > pass; > pass; > done_testing() # optional > > Then, you can incrementally build a plan for those who want it and it seems > backwards almost compatible (since done_testing() wouldn't be required). >

Re: done_testing()

On Feb 4, 2009, at 3:15 PM, Ovid wrote: Only one. The BBC frowns on it if you come back *completely* wasted. I'd probably get a stern talking to if I did. Ooh, scary. D

Re: done_testing()

- Original Message > From: David E. Wheeler > > (The first idea is bugging me because I swear I had thought of a > > show-stopper > over lunch, but for the life of me, I can't recall what it was). > > Must've been a damn good lunch. How many pints did you kill? Only one. The BBC fr

Re: [test-more-users] Re: done_testing()

Hello, On Feb 4, 2009, at 10:35 PM, Ovid wrote: Thoughts on first order support: use Test::More; plan(3); pass; pass; pass; plan(2) pass; pass; done_testing() # optional I just made a branch of Test::Builder which does this. You can see the expected behaviour in the tests at: http

Re: done_testing()

On Feb 4, 2009, at 6:35 AM, Ovid wrote: Thoughts? (The first idea is bugging me because I swear I had thought of a show-stopper over lunch, but for the life of me, I can't recall what it was). Must've been a damn good lunch. How many pints did you kill? D

Re: done_testing()

t::Builder and Test::More for it, but > for the moment this will work: > > use Test::More; > > my $tests = 2; > pass; > pass; > > $tests += 1; > pass; > > done_testing($tests); Thoughts on first order support: use Test::More; plan(

done_testing()

Well it's about damn time. use Test::More; pass; done_testing; This now works and effectively replaces no_plan. This works, too: use Test::More; pass; done_testing(1); I was expecting it to be hard and require a lot of reworking the tests. It turns out it was really easy,