- Original Message
> From: Matisse Enzer <[EMAIL PROTECTED]>
> > Should be fairly easy to implement with the new Test::Harness.
> What
> > syntax would be desired? Also, it seems to me that you've two
> > different cases. Have the entire suite BAIL_ON_FAIL or have an
> > individual
On Nov 19, 2007, at 10:28 AM, Geoffrey Young wrote:
"BAIL_ON_FAIL" approach to running a test suite - a settings that
determines how many failures before the whole test run stops. Default
would be to keep running no matter how many failures, but you could
set
it to 1 and then bam, the whole
Matisse Enzer wrote:
>
> On Nov 18, 2007, at 3:50 AM, Michael G Schwern wrote:
>
>>
>> I start at the top, read the first few failures, fix them and rerun.
>> I ignore
>> the bulk of a really large failure as they're probably just cascades
>> of the
>> one mistake.
>
> This reminds me - I was
On Nov 19, 2007, at 1:36 AM, Ovid wrote:
- Original Message
From: Matisse Enzer <[EMAIL PROTECTED]>
This reminds me - I was wondering what it would take to implement a
"BAIL_ON_FAIL" approach to running a test suite
...
Should be fairly easy to implement with the new Test::Harne
On 19 Nov 2007, at 09:36, Ovid wrote:
Should be fairly easy to implement with the new Test::Harness. What
syntax would be desired? Also, it seems to me that you've two
different cases. Have the entire suite BAIL_ON_FAIL or have an
individual test program halt on failure. The latter seems
- Original Message
> From: Matisse Enzer <[EMAIL PROTECTED]>
> This reminds me - I was wondering what it would take to implement a
> "BAIL_ON_FAIL" approach to running a test suite - a settings that
> determines how many failures before the whole test run stops. Default
> would be t
On Nov 18, 2007, at 3:50 AM, Michael G Schwern wrote:
I start at the top, read the first few failures, fix them and
rerun. I ignore
the bulk of a really large failure as they're probably just cascades
of the
one mistake.
This reminds me - I was wondering what it would take to implement
nadim khemir wrote:
> I spend a rather large amount of time writing and running tests. There are a
> few things that could be better. I either don't know how or it may not
> possible. I thought we could share some of questions and ideas that can make
> working with tests more pleasent. This sho