* Michael G Schwern <schw...@pobox.com> [2009-02-19 06:35]: > Aristotle Pagaltzis wrote: > > 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.
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. 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. Using the numbering scheme to indicate these failures, however, would be fine. That’s what I was trying to say. Sorry it was less than clear. > 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. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
