Re: Mapping test cases to bug databases

2004-07-07 Thread Michael G Schwern
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

Re: Test functions return values.

2004-07-07 Thread Michael G Schwern
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(),

Re: Test::Inline should not capture STDOUT, STDERR

2004-07-07 Thread Michael G Schwern
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.

Re: Test::Inline should not capture STDOUT, STDERR

2004-07-07 Thread Andrew Pimlott
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

Re: Test::Inline should not capture STDOUT, STDERR

2004-07-07 Thread Michael G Schwern
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

Re: Test::Inline should not capture STDOUT, STDERR

2004-07-07 Thread Andrew Pimlott
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

Re: Test::Inline should not capture STDOUT, STDERR

2004-07-07 Thread chromatic
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