chromatic wrote: > One issue that hasn't come up much is that you can't always rely on STDERR > being available when a human looks at the test results. > > Think of testing long-running programs in process, testing in the browser > (whether via JavaScript Test.Builder or Apache::Test), and automated smoke > tests. > > Sure, dumping diagnostics to STDERR works fairly well when a human enters > the > command to run the tests and sits in front of the controlling terminal and > can scroll back to see the STDERR output, but that's not the only case of > running tests at all (and getting diagnostic output is much, much more > useful > when you don't have access to the particular computer where the tests > fail).
Another way of saying that is that TAP is at heart a file/stream format, and where it tries to be something else, it loses benefits that come with that (merging STDOUT/STDERR and the bailout function being two instances that spring to mind).
