On Wed, Jul 07, 2004 at 05:46:12PM -0400, Michael G Schwern wrote:
> 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.
Interesting. Aside: I'm glad to have it, as the whole plan business
was one of the turn-offs of the standard Test modules in the past. Is
the tedium of counting tests really worth it for anyone? Wouldn't it
have been better to make the harness look for something like "all done
testing" to verify that the tests completed?
Along these lines, would you consider making 'no_plan' the default?
People who want plans will use them without being badgered, and for the
rest of us it's just hassle.
> 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.
To be fair, "use Test::More 'no_plan'" is what I would be doing anyway,
but I don't mind (and slightly prefer, aesthetically) saying it
explicitly.
> 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.
Of course, in theory this would be great. One of the ways in which the
line is blurred is that while the tied handle machinery is set up in
pod2test, the
undef $main::_STDOUT_;
lines are in Pod::Tests. Of course, these lines are harmless by
themselves (so when I modified my version, I just removed the part in
pod2test and left Pod::Tests untouched), but it would be cleaner to
handle both in the same place.
> So little to do, so much time. Strike that, reverse it.
http://www.imdb.com/title/tt0367594/
> 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;
I would be happy with something like this. Of course, you know which
one I would prefer to be the default. BTW, wouldn't that last one have
to be
trap \$__STDOUT__, *STDOUT;
or is there some trick I'm missing?
Andrew
