Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

nik (3476)

AOL IM: nikclayton (Add Buddy, Send Message)

Journal of nik (3476)

Saturday December 04, 2004
11:50 AM

Test::Harness's TAP in C -- libtap

[ #22137 ]

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.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • Back [] to back [] entries on C implementations [] of Test::Harness. Odd, huh? ;)
    • 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

  • Why have three separate plan functions?

    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.

    • Why have three separate plan functions?

      Rough consensus on -- 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 []).

      • 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.