If added to Test::Warn I'd argue for separate functions. I've had situations where warnings were logged, and STDERR was meant for user readable output. Having them merged would break some tests of mine (not many - I won't be *that* upset if everybody disagrees with me ;-).
I always meant to revisit the idea for Test::Output which was intended to be a generic FILEHANDLE output testing module. Allows you to do things like:
output_is { hello() } "hello world\n", STDOUT, "hello world";
output_isnt { hello() } "goodbye", STDOUT, "not goodbye";
output_unlike { hello() } qr/bye/, STDOUT, "didn't print bye";
output_like { hello() } qr/hello/, STDOUT, "printed hello";
like(Test::Output->last, qr/world/, "... and world");Which (I think) would do all that you need.
(Draft implementation of above at <http://www.quietstars.com/perl/>)
However, I'm not really happy with the above API and haven't had the time to think about it in any more detail. Suggestions welcome :-)
Cheers,
Adrian
On Thursday, February 27, 2003, at 05:16 pm, [EMAIL PROTECTED] wrote:
As comes up pretty often, people want to trap stuff on STDERR. I've got
adhoc stuff to do that in TieOut.pm, but I've never really found a good
place to put it in a module.
Test::Warn seems like its a good spot. Warnings and stuff going directly
to STDERR are related beasts. So if Janek wants it, I can patch Test::Warn
to trap STDERR was well as normal warnings.
The question is the interface. Should warning* just trap STDERR like any other warning or should there be seperate functions?
I'd argue for the former. First from a DWIM standpoint, and second because sometimes you'll be getting both warnings and output to STDERR from the same code (as just happened to me, prompting this train of thought) and it would be nice to trap both.
The downside is the two streams are mixed and can't be seperated by the test without unnecessarily complicating the arguments to warning*. Dunno how important this is, don't think its very.
