On Wed, Jul 07, 2004 at 05:18:44PM -0400, Andrew Pimlott wrote: > > pod2test is poorly architected but I don't see anything it does that > > I'd want in a module. What were you thinking of? > > I was mostly thinking about the capturing of STDOUT and STDERR, but I'm > alsa suggesting it as a general principle. I guess the only other thing > is the automatic > > use Test::More 'no_plan'; > > This is probably harmless, but on the other hand it's trivial to include > it yourself, so I don't see the point.
I think I threw that in before I realized one could just do: =for testing use Test::More 'no_plan'; This was all very early on in my mucking with the Test:: modules. In fact, no_plan was implemented specificly so I could do Test::Inline. Test::Inline is written to optimize what I think is the most common case of writing inline tests and avoid having to write a lot of repetitive top matter. I'm probably wrong and because of that would like to avoid forcing my faulty assumptions on others. Best thing to do is more sharply draw the line between Pod::Tests and Test::Inline so that one can remove Test::Inline and just use the Pod::Tests parser to construct their own .t files. Much in the same way that Test::More's guts became Test::Builder. So little to do, so much time. Strike that, reverse it. > Someday we will all be using Test::Most instead. (waitaminnit... > search.cpan.org... whew, not there yet) Test::Donny::Most. > > Also, --no-trap-stdout and --no-trap-stderr options might be in order. > > I would much rather encode these directives in the POD than in the > command line. Yes, I think I agree. Syntax is easy. Here's to shut it off: =for testing no_trap *STDOUT, *STDERR; And turn it on. =for testing $__STDOUT__ = trap *STDOUT; $__STDERR__ = trap *STDERR; -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern/ I'm exploring my nipples.
