On Mon, May 24, 2004 at 02:55:34PM +1000, Andrew Savige wrote:
Suppose I fix a bug with a unique bug ID in a bug tracking system.
I start by dutifully adding 15 new asserts, say, to an existing unit
test program, to duplicate the bug before I fix it. What if I later
want some way to map the
On Tue, May 25, 2004 at 09:16:51AM -0700, chromatic wrote:
On Tue, 2004-05-25 at 06:58, Francisco Olarte Sanz wrote:
I've been looking at the documentation for the test modules (Test::More,
Test::Simple, Test::Builder ), and I've found nothing regarding the return
value of the ok(),
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