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.
Re:Strange
nik on 2004-12-05T00:49:42
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 write tests in C. I think someone's mentioned having an equivalent library for PHP too.
TAP in PHP
geoff on 2004-12-05T20:50:21
see the end of this file for a PHP implementation.
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...
nik on 2004-12-05T08:32:37
Why have three separate plan functions?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).
Re:comments on plan...
rooneg on 2004-12-05T18:49:12
Interesting. I like the old way much better, the multiple different plan functions seems like it makes the C version different from the perl version when there's no good reason to do so.
