All the Perl that's Practical to Extract and Report
use Perl Log In
nik (3476)
Test::Harness's TAP in C -- libtap
A few weeks back I did the work to make most of the FreeBSD regression test suite produce output that's compatible with Test::Harness and prove(1).
Back then there wasn't a name for that format. Now, of course, there is.
This was very much a rough cut. A lot of the tests were written in C, consisting of a few hundred (or in some cases a few thousand) ASSERT() calls, with a printf("PASS\n"); at the bottom -- if your test didn't dump core you knew it worked.
Changing most of those to add printf("1..1\n"); and printf("ok 1\n"); was the work of an afternoon.
On the TODO list was to implement as much of TAP as possible in C -- having plans, ok(), and so on. By doing that, and removing the ASSERT()s, a failing test doesn't prevent all the other tests from running, and you get a truer picture about how many tests overall are being run. And we all know that seeing the test count go up is a strong incentive to keep writing them.
So, here's a very early draft of that; libtap. Right now, plan(), ok(), and diag() functionality is there, which is almost all the way to what I need for FreeBSD regression suite.
have an eval. In such cases, immediate and radical amputation of the
power cord is the only recourse.
--Larry Wall
Strange (Score:1)
Re:Strange (Score:1)
We've done slightly different things. My code still expects the tests to run by something like Test::Harness' runtests(), and produces output that is (supposed to be) 100% compatible with that produced by Test::More under the same circumstances.
My take on this is that we really only need one 'harness' and protocol, and Test::Harness/TAP does a good job of being that. But there's no reason why the tests themselves have to be written in Perl, which is where libtap comes in, making it a little easier to wr
TAP in PHP (Score:2)
comments on plan... (Score:1)
I would have thought you'd just do a single 'plan' function, which takes an integer as its first arg and then varargs after that.
Define constants like NO_PLAN and SKIP_ALL as negative numbers, a positive number for the first arg corresponds to the current plan_tests, NO_PLAN as the first arg corresponds to plan_no_plan, SKIP_ALL corresponds to plan_skip_all, and you grab the string from the varargs to get the equivalent of the current plan_skip_all's argument.
Re:comments on plan... (Score:1)
Rough consensus on #london.pm -- originally the code did much as you suggest (although it looks like I didn't commit that, there's a hangover from it in one of the test files [ngo.org.uk]).
Re:comments on plan... (Score:1)