On 7/4/06, Ovid <[EMAIL PROTECTED]> wrote:
---- Original Message ----
From: Jonathan Rockway <[EMAIL PROTECTED]>
> 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.)
From the discussion here, anything which is not recognized as TAP output is
discarded, so those warnings probably won't matter unless they look like a test
plan or a test line.
I'm finding myself more and more liking this feature of TAP and
reversing my "will become more stringent in the future" declaration.
If nothing else it makes backwards compatibility with older TAP
parsers a lot easier to deal with.
Anyhow, TAP says nothing about STDOUT or STDERR. It just wants a
stream of text. If your TAP source decides to blend STDOUT and STDERR
together and feed it to the TAP parser, it can do that.
> 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 ...
Unless I'm greatly mistaken, the is outside the scope of TAP. TAP is merely a
protocal and where it gets written to/read from should be irrelevant.
Mandating that would only impose extra overhead.
More importantly it would limit us to executing local programs on
systems with good filehandle support. Consider the case of accepting
TAP by fetching an HTTP uri. No filehandles there. I'm sure you
could fake it, but then all your simplicity is gone.
