On Wed, Jul 07, 2004 at 05:12:20PM -0700, chromatic wrote:
Add no_plan while you're writing tests, run the tests, then when you're
done, change the plan to reflect the number of tests to run. I have a
brain-dead simple vim mapping to do just that.
Aside: Would be good if someone maintained
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.
On Wed, Jul 07, 2004 at 02:42:22PM -0400, Michael G Schwern wrote:
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
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
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
On Wed, 2004-07-07 at 17:07, Andrew Pimlott wrote:
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?
Tedium is the mother of invention.
Add
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::
