Eric Wilhelm wrote:
What it protects you from is dying half-way through the tests
without the harness noticing...
Death is noted by both Test::More and Test::Harness and has been for a
long time
The only way you can abort the test halfway through using no_plan and
get a success is with an e
Eric Wilhelm wrote:
# from Aristotle Pagaltzis
# on Sunday 30 March 2008 23:14:
Except that the test program might be running at the other end of
an HTTP connection. Or at the other end of a serial port. Or the
harness might be parsing an archived TAP stream. Or a TAP archive
generated offline
# from Aristotle Pagaltzis
# on Sunday 30 March 2008 23:14:
>Except that the test program might be running at the other end of
>an HTTP connection. Or at the other end of a serial port. Or the
>harness might be parsing an archived TAP stream. Or a TAP archive
>generated offline in batch mode. Or…
# from Michael G Schwern
# on Sunday 30 March 2008 22:57:
>> What it protects you from is dying half-way through the tests
>> without the harness noticing...
>Death is noted by both Test::More and Test::Harness and has been for a
> long time
>
>The only way you can abort the test halfway throu
* Michael G Schwern <[EMAIL PROTECTED]> [2008-03-31 08:00]:
> Aristotle Pagaltzis wrote:
>> What it protects you from is dying half-way through the tests
>> without the harness noticing. Of course, that’s by far the
>> most common failure mode.
>
> I don't want to drag out the "plan vs no_plan" arg
Aristotle Pagaltzis wrote:
Note that it doesn’t quite protect you from running too few tests
either. You may botch some conditional in your test program and
end up skipping tests silently, in which case you will still
reach the `all_done()` line, and it’ll look as if all was fine.
The typical a
Hi Buddy,
* Buddy Burden <[EMAIL PROTECTED]> [2008-03-31 00:05]:
> Well, do you agree with this assessment:
>
> Having a plan stated as an exact number of tests to be run is a
> solution to 2 problems. The first is that a test harness must
> be able to tell when not enough tests have been run. The
On Sunday 30 March 2008 14:57:35 Buddy Burden wrote:
> And/or, it may make sense to use
> deferred plans during development, but switch to numeric plans before
> releasing anything to CPAN.
That's what I do. I have a pair of Vim macros which toggle my plans.
-- c
Aristotle,
> > But when it comes to testing, doing this in terms of tests is
> > not only okay, it's considered best practice.
>
> No, just intrinsically inevitable, as far as I can tell anyway.
Well, do you agree with this assessment:
Having a plan stated as an exact number of tests to be ru
* Buddy Burden <[EMAIL PROTECTED]> [2008-03-29 20:55]:
> I just think that having code where every time you change
> things in one place, you have to make sure you change something
> somewhere else isn't a good thing. In any other programming
> scenario, I think most everyone would agree with me.
10 matches
Mail list logo
