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 outputting extra tests to force a failure means > that suddenly a test result does not just represent the result of > a test, but can also be a signal that the incremental plan failed > to pan out. You’ve added a new meaning to the syntax for test > results.
What do test results mean but that an assertion failed? A sub-plan is an assertion. > Worse, though, if you output these only sometimes, a TAP consumer > which wants to extract this information will need funky logic to > deal with the conditional presence of these tests. I admit that having tests which only show up on failure is weird, which is why if it went that way the test result would always be there, but it doesn't require any extra TAP reader logic to determine pass or fail. >> So something like this? […] Not such a bad idea, and pretty >> straight forward if each plan( add => # ) is considered a test >> itself. > > Yes, exactly like that. I still don’t quite like it. I can see, > though, that using the numbering to communicate this while > keeping TB-dependent code working could be a problem, whereas > this version would be feasible – in which case at least there > is a certain logic to it, and the subplan stages could be > interpreted by TAP consumers with much less complex condition > checks than the output you proposed. -- Defender of Lexical Encapsulation
