>> Anything else >> Any output line that is not a plan, a test line or a diagnostic is >> incorrect. How a harness handles the incorrect line is undefined. >> Test::Harness silently ignores incorrect lines, but will become more >> stringent in the future.
This leads me to another question -- what to do about output that the program prints to STDOUT or STDERR? There are some modules that I use that insist on C<warn>-ing whenever something weird happens... will these mess up my tests? (They don't *now*, but that's because Test::Harness is being overly nice.) What would happen if TAP dictated that TAP output be sent to an extra filehandle? For example, prove could open filehandle 3, fork the test process, and collect TAP data on descriptor 3 while the usual program output is written to STDOUT and STDERR. This would make diagnostic output easier; it's just a normal print statement. If you wanted to truly please DJB (with his "don't parse" mantra), then you could open two extra filehandles, one for 'ok' and one for 'not ok', and print the number of the test mod 256 (i.e. one byte per test, no newline; just the byte) to each handle. If it comes in on pipe one and the number is where it should be, it's a 'ok #', if it comes in on that second pipe, it's a 'not ok #'. Now that I think about it, though, I'm not sure if this causes problems or solves problems. :) Comments? Regards, Jonathan Rockway
signature.asc
Description: OpenPGP digital signature
