Aristotle Pagaltzis wrote:
> * Michael G Schwern <schw...@pobox.com> [2009-02-18 22:45]:
>> Aristotle Pagaltzis wrote:
>>> * Michael G Schwern <schw...@pobox.com> [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 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
> than that the existing codebase has inadequacies in exposing the
> full existing semantics.
Sorry, you've lost me. What?
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.
> New tools will forever have to make special accomodations to
> interpret this crud correctly just because the old ones were
> inadequate at some point in time. I understand that the TB API
> can’t just be changed to accommodate this either… it’s a
> difficult problem. But I’d prefer if some more thought went into
> how to proceed, rather than just going forward with whatever’s
> expedient.
This would be why I posted the question. I was in the middle of writing up
some plan add tests and still don't know how best to handle a sub-plan overrun.
> I might be more comfortable if using `plan add` counted as an
> assertion itself, so it would *always* emit a test result, and
> you’d get N extra tests (properly accounted for in the plan, of
> course) if you called `plan add` N times. I’m stil 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;
pass("second");
pass("third");
# Four tests, plus the two sub-plans.
done_testing(6);
Would produce:
ok 1 - first
not ok 2 - sub-plan at line 3
# 2 planned, but only 1 ran
ok 3 - second
ok 4 - third
ok 5 - sub-plan at line 7
1..6
Not such a bad idea, and pretty straight forward if each plan( add => # ) is
considered a test itself.
--
You know what the chain of command is? It's the chain I go get and beat you
with 'til you understand who's in ruttin' command here.
-- Jayne Cobb, "Firefly"
