On 12/03/07, Michael G Schwern <[EMAIL PROTECTED]> wrote:
Michael G Schwern wrote:
> Subroutines? I don't know if I follow. Do you mean...
>
> sub foo {
> extend(2);
>
> pass();
> bar();
> pass();
> }
>
> sub bar {
> extend(3);
> pass();
> pass();
> pass();
> }
>
> I believe that can be made to work without a TAP extension. Its the
> producer which does the stack watching and generates the errors instead of
> the TAP parser.
As a matter of fact, thinking about it more, this sort of thing has to be
able to work in the TAP producer. How else will it know what group its
currently in to output the appropriate TAP?
Yes, the producer must track the stack but now you're also forcing it
to verify the plan which is consumer's job. I think that's acceptable
when we've fallen back to be compatible with an old consumer.
Here's another proposal that I think might work. The only plan that
really needs to be checked by the consumer is the overall plan. Within
the producer, we can consider a containing block to be the consumer
and be responsible for checking the plan without any loss of
strictness modulo bugs in the producer (not the test script but the
TAP producing library). So all that's really I need is a way to say
that some tests should not count towards the overall plan but they are
real tests that must not fail either. Going back to the original
example
1..3
1 ok
2 1..2 # start a block
2.1 1..3 # start another block
2.1.1 ok
2.1.2 ok
2.1.3 ok
2.1 ok # inner block was all good
2.2 ok
2 ok # outer block was all good
3 1..3
3.1 ok
3.2 ok
3 not ok # planned for 3 but only ran 2 tests
I care that everything is "ok" but from a plan point of view, I only
need Test::Harness to check that I gave a result for
1 ok
2 ok # outer block was all good
3 not ok # planned for 3 but only ran 2 tests
It should tell me if 2.1.2 said "not ok" but it should not count it
towards the plan.
I suppose this could be hacked up by doing the extends _after_ each
outer block finishes, although that's no good for the fork/thread use
case.
F