--- Michael G Schwern <[EMAIL PROTECTED]> wrote:
> > Set a flag that T::B should quit when the next test result is
> > about to be recorded?
>
> I guess it works, but it leaves you dead halfway through another test
> function which is weird.
The code I sent is conceptually similar, but since a f
--- Michael G Schwern <[EMAIL PROTECTED]> wrote:
> PS Couldn't you have the TAP harness kill the test process on first
> failure?
I then have even less control over the diagnostics than I would if
Test::Builder handled this responsibility.
It's also an improper separation of concerns. Test::Bu
Aristotle Pagaltzis wrote:
> * Michael G Schwern <[EMAIL PROTECTED]> [2008-01-12 12:00]:
>> Ovid wrote:
>>> I'll go fix that diagnostic thing now. Unfortunately, I
>>> think I'll have to violate encapsulation :(
>> If you know how to fix it let me know, because other than
>> enumerating each testin
Ovid wrote:
> --- Michael G Schwern <[EMAIL PROTECTED]> wrote:
>
>> The whole idea of halting on first failure was introduced to me by
>> some XUnit
>> folks ... As any field scientist knows, there's no such thing as
>> uncontaminated data.
>
> As any tester knows, a "one size fits all suit" ofte
* Michael G Schwern <[EMAIL PROTECTED]> [2008-01-12 12:00]:
> Ovid wrote:
> > I'll go fix that diagnostic thing now. Unfortunately, I
> > think I'll have to violate encapsulation :(
>
> If you know how to fix it let me know, because other than
> enumerating each testing module you might use and le
--- Michael G Schwern <[EMAIL PROTECTED]> wrote:
> The whole idea of halting on first failure was introduced to me by
> some XUnit
> folks ... As any field scientist knows, there's no such thing as
> uncontaminated data.
As any tester knows, a "one size fits all suit" often doesn't fit. Let
peop
The whole idea of halting on first failure was introduced to me by some XUnit
folks. Their rationale was not to avoid spewing output, they had no such
problem since it's all done via a GUI, but that once one failure has happened
the failing code might hose the environment and all following results
Ovid wrote:
> I'll go fix that diagnostic thing now. Unfortunately, I think I'll
> have to violate encapsulation :(
If you know how to fix it let me know, because other than enumerating each
testing module you might use and lex-wrapping all the functions they export,
I'm not sure how to do it. T
--- Geoffrey Young <[EMAIL PROTECTED]> wrote:
>
> > There are two usual rebuttals.
>
> the third being "just add it and let me decide"
>
> :)
Right in one!
I'll go fix that diagnostic thing now. Unfortunately, I think I'll
have to violate encapsulation :(
As a side note: after reading ev
There are two usual rebuttals.
the third being "just add it and let me decide"
:)
--Geoff
On 12/01/2008, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> --
> 184. When operating a military vehicle I may *not* attempt something
> "I saw in a cartoon".
> -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army
>http://skippyslist.com/?page_id=3
That was on
Ovid wrote:
> I've posted a trimmed down version of the custom 'Test::More' we use
> here:
>
> http://use.perl.org/~Ovid/journal/35363
>
> I can't recall who was asking about this, but you can now do this:
>
> use Our::Test::More 'no_plan', 'fail';
>
> If 'fail' is included in the import li
On Friday 11 January 2008 14:19:52 Ovid wrote:
> So imagine you have a Web spider with 1000 tests and it fails at the
> third test. If the behavior is in the harness, it stops processing
> results but the test program keeps running unless you deliberately try
> to kill the process. I think it's
On 11 Jan 2008, at 22:19, Ovid wrote:
HARNESS_SKIP_ON_FAIL => Stop the failing test program on first
failure
Remember that neither of those can really stop the test program from
running. The first could halt *subsequent* test programs from running
and the second could merely discard subsequent
--- Andy Armstrong <[EMAIL PROTECTED]> wrote:
> HARNESS_BAIL_ON_FAIL => Stop the whole run on the first failure
>
> And perhaps for completeness:
>
> HARNESS_SKIP_ON_FAIL => Stop the failing test program on first
> failure
Remember that neither of those can really stop the test program from
run
On 11 Jan 2008, at 18:32, Eric Wilhelm wrote:
And I don't want to hack Test::More - I want this as a new feature in
the "real" Test::Builder, so anything build on Test::Builder gets
this behavior.
Can it just be in the harness?
I'd have thought so.
HARNESS_BAIL_ON_FAIL => Stop the whole r
# from Matisse Enzer
# on Friday 11 January 2008 10:26:
>And I don't want to hack Test::More - I want this as a new feature in
> the "real" Test::Builder, so anything build on Test::Builder gets
> this behavior.
Can it just be in the harness?
--Eric
--
To a database person, every nail looks l
On Jan 11, 2008, at 10:09 AM, Ovid wrote:
--- Matisse Enzer <[EMAIL PROTECTED]> wrote:
On Jan 11, 2008, at 8:04 AM, Ovid wrote:
Well, your feature is slightly different in that it calls BAIL_OUT
on
failure and halts the entire test suite.
That's a behavior I have wanted - for large tes
--- Matisse Enzer <[EMAIL PROTECTED]> wrote:
>
> On Jan 11, 2008, at 8:04 AM, Ovid wrote:
> >
> > Well, your feature is slightly different in that it calls BAIL_OUT
> on
> > failure and halts the entire test suite.
>
> That's a behavior I have wanted - for large test suites being used
> during
On Jan 11, 2008, at 8:04 AM, Ovid wrote:
Well, your feature is slightly different in that it calls BAIL_OUT on
failure and halts the entire test suite.
That's a behavior I have wanted - for large test suites being used
during development for example. I just want to stop the whole test run
--- Geoffrey Young <[EMAIL PROTECTED]> wrote:
> we've discussed this a few times on this list, and I even submitted a
>
> patch to make it so:
>
>http://www.mail-archive.com/perl-qa@perl.org/msg08973.html
>
> your interface is very nice, but I think I'd also like to preserve
> the
> abilit
Ovid wrote:
I've posted a trimmed down version of the custom 'Test::More' we use
here:
http://use.perl.org/~Ovid/journal/35363
I can't recall who was asking about this, but you can now do this:
use Our::Test::More 'no_plan', 'fail';
If 'fail' is included in the import list, the test pro
I've posted a trimmed down version of the custom 'Test::More' we use
here:
http://use.perl.org/~Ovid/journal/35363
I can't recall who was asking about this, but you can now do this:
use Our::Test::More 'no_plan', 'fail';
If 'fail' is included in the import list, the test program will die
im
23 matches
Mail list logo
