On 11/03/07, Michael G Schwern <[EMAIL PROTECTED]> wrote:
A. Pagaltzis wrote:
> * Michael G Schwern <[EMAIL PROTECTED]> [2007-03-11 12:55]:
>> Why does this need a TAP mod? Why not let the producer handle
>> it?
>
> Because then all you can do is a global trailing plan which is
> only half a step up from no plan?
Yep. And why is that a problem?
> And if the tests and plan disagree, how do you localise the group
> in which they diverged? It's easy as falling off a log if you
> have sub-plans.
plan add => 2;
pass;
pass;
pass;
plan add => 3;
pass;
pass;
ok 1
ok 2
no ok 3
# Planned 2 sub-tests at line 1 but ran 3!
ok 4
ok 5
# Planned 3 sub-tests at line 6 but only ran 2!
1..5
The TAP producer can do it.
You're suggesting that each call to extend the plan verifies that the
previous plan has been executed fully? That does not allow nesting.
Translating from my proposal to the above:
1 1..3
1.1 ok
1.2 1..2
1.2.1 ok
1.2.2 ok
1.2 ok
1.3 ok
becomes
1 ok # was 1.1
# Planned 3 sub-tests at line 1 but only ran 1!
2 ok # was 1.2.1
3 ok # was 1.2.2
4 ok # was 1.3
1..4
There's also the issue of passing important error messages as text
embedded in diags.
Finally, it doesn't help with counting. Take this example
use Test::More tests => 10;
my @tests = (...); # ten things
for my $t (@test) {
is($t, foo);
}
now if I want to change this to
for my $t (@test) {
is($t, foo);
is($t, bar);
}
I must update the global plan and start multiplying things. With
blocks I can just do
for my $t (@test) {
block {
plan 2;
is($t, foo);
is($t, bar);
}
}
becase the plan of each block is counted as a single test in it's
enclosing block. With plan extensions I would either do
use Test::More tests => 10;
my @tests = (...); # ten things
for my $t (@test) {
is($t, foo);
extend 1;
is($t, bar);
}
which is clearly broken and will cause lots of confusion when you
squirrel your tests away in subroutines. Or
use Test::More tests => 0;
my @tests = (...); # ten things
for my $t (@test) {
extend 2;
is($t, foo);
is($t, bar);
}
which will happily exit early with 0 tests run and no errors,
F
> I thought the benefits of local plans are dead obvious.
When you're talking about extending a protocol that everyone has to obey
forever and ever, you try not to leave things to "obvious".
