Eric Wilhelm wrote: > # from Michael G Schwern > # on Tuesday 27 January 2009 18:16: > >> 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. > > So, > > 1. TAP::Harness should store that when archiving?
Yes, it's just a test like any other. 1..3 ok 1 ok 2 ok 3 not ok 4 - exited with status 1 That will cause both a test failure and a plan failure. Alternatively, you can plan to issue a final exit status test, it's really stylistic. > 2. Is it possible to have something more explicit than that? (or does > the exit code go in the test name or what? At the moment, nothing more than the description. In the future, yes. This use case came up at the Oslo hackathon. First TAP extension allows structured diagnostics associated with each test, so you can put the information in explicitly. 1..3 ok 1 ok 2 ok 3 not ok 4 - exited with status 1 --- exit: 1 ... (I keep forgetting that the structured diagnostics are indented) Beyond that, meta data for the whole test suite was proposed to record things which otherwise would not be recorded such as time, versions, system information, etc... as well as things like exit codes. http://testanything.org/wiki/index.php/TAP_meta_information It might look like this: TAP version 15 --- file: foo.t date: 2009-01-28 16:26:07 uname: Darwin 9.6.0 ... 1..3 ok 1 ok 2 ok 3 --- exit: 1 ... Or consider if you're reading the TAP stream from a web server and archiving it: TAP version 15 --- url: http://example.com/test.tap date: 2009-01-28 16:26:07 server: Apache/2.2.9 (Unix) ... 1..2 ok 1 ok 2 --- http status: 200 ... As you can see, it's ambiguous whether that final bit of information is associated with the last test or is trailing suite meta data. I don't recall if we had a solution to that. -- 185. My name is not a killing word. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
