On Fri, Jun 04, 2004 at 10:18:37PM -0400, Andrew Pimlott wrote: > I started using Test::Inline, and I have two related comments. (I hope > this is the right place to bring them up.) > > 1. I don't think that pod2test should do anything more than the minimum > to construct a valid test script. Anything else that is useful > should be part of the standard Test:: modules.
pod2test is poorly architected but I don't see anything it does that I'd want in a module. What were you thinking of? > 2. I don't like it capturing STDOUT and STDERR when I don't ask for it. > I realize that well-behaved tests shouldn't write directly to > STDOUT, but since the point of tests is that code is not always > well-behaved, it's nice to get the clues that STDOUT and STDERR may > provide. There are of course better ways to capture this output > when that's desired. You did ask for it, you used Test::Inline. :) Not buying that one? Its rarely useful for a test to output to STDOUT. Can you think of a non-contrived example where it would be desirable? OTOH, example code often involves printing. So trapping STDOUT seems obvious to me. STDERR is another issue. Lots of interesting information might go out to STDERR during a failure that you'd like to see. But again, examples often call warn. Since trapping STDOUT/ERR is really only useful for example code, maybe T::I should stop doing it for test blocks. That still leaves warnings in examples. One can write "is $__STDERR__, ''" but it would happen at every example block and that gets tedious. Perhaps T::I can get smart. If $__STDERR__ is not looked at in the example_testing block an implied "is $__STDERR__, ''" is run. Simple enough since $__STDERR__ is a tied variable. That would seem to solve the problem. Also, --no-trap-stdout and --no-trap-stderr options might be in order. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern/ It's Flypaper Licking time!
