Buddy Burden wrote:
Not criticizing, not claiming my method is better, just looking for
any reasons why this wouldn't work. And, JIC there's some agreement
that it _would_ work, I've already put together a patch for Test::Most
that does it. That is, at the top of your script, you put this:
chromatic,
> Any solution which requires a human being to read and think about the output
> beyond "It's all okay!" or "Something fell!"* is not a long-term solution.
I don't think that's true of this implementation. If the script
doesn't reach the all_done() call, there is a very obvious erro
On Saturday 29 March 2008 12:51:34 Buddy Burden wrote:
> The first is that _during development_, I want to stop my tests on the
> first failure.
Get a better harness.
> The second sticking point is the concept of plans, and here is where I
> really want to understand the reasoning behind it. My
I debated whether or not to post this here for a long time, because I
gather that deferred plans are somewhat of a hot topic on this group.
But finally I decided that I just needed to understand some history
and make sure there's nothing I'm missing here.
First, if you'll bear with me, a little
Hi Michael,
* Michael G Schwern <[EMAIL PROTECTED]> [2008-03-29 11:35]:
> Stumbled across this while finding an alternative to libtap for
> testing C (it has some sort of issue linking with this hairy
> project I'm working on). Apparently MySQL wrote their own TAP
> library for C.
>
> From http://
Stumbled across this while finding an alternative to libtap for testing C (it
has some sort of issue linking with this hairy project I'm working on).
Apparently MySQL wrote their own TAP library for C.
From http://dev.mysql.com/doc/mysqltest/en/unit-test.html
The unit-testing facility is based
