chromatic wrote: > On Friday 23 January 2009 20:48:57 Michael G Schwern wrote: > >> But these days a TAP parser can catch most premature exits by just looking >> at the exit code of the test, so the plan is less useful than it once was. > > That assumes that the TAP parser has some degree of control over the TAP > emitter, which is an assumption I would like people to stop making > universally.
FWIW this is addressed in the TAP spec by stating a TAP parser may rely on things outside the TAP stream to effect pass/fail but should avoid it where possible and instead encode it in TAP. http://testanything.org/wiki/index.php/TAP_at_IETF:_Draft_Standard#Other_Things_Which_Can_Affect_Suite_Passing Other Things Which Can Affect Suite Passing A parser may take into consideration information about the program emitting the TAP in determining if a suite passes or fails. For example, if the exit code of the process indicates a failure (such as with a non-zero exit code), the parser might determine the test to have failed. This is useful for catching things such as a test program crashing after it has finished emitting TAP. A TAP producer should not rely on this feature. It should when possible encode the failure as TAP. For example, if a test program knows that it is going to exit abnormally, even after it has finished emitting TAP according to its plan, it should emit one final "not ok" line before exiting. This is to ensure that all TAP consumers discover the failure, and SHOULD be emitted even when doing so would violate the plan. -- But there's no sense crying over every mistake. You just keep on trying till you run out of cake. -- Jonathan Coulton, "Still Alive"
