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
