Stories
Slash Boxes
Comments
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • Back [perl.org] to back [perl.org] entries on C implementations [perl.org] 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 #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]).

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