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

use Perl Log In

Log In

[ Create a new account ]

chromatic (983)

chromatic
  (email not shown publicly)
http://wgz.org/chromatic/

Blog Information [technorati.com] Profile for chr0matic [technorati.com]

Journal of chromatic (983)

Tuesday April 08, 2008
12:39 AM

Porting Test::Class to PIR

[ #36097 ]

Adrian Howard's Test::Class is one of my favorite Perl modules. It makes organizing large test suites and improving test coverage much easier.

Parrot has a lot of tests, but probably half or a third of what it needs. Parrot testing is an interesting hodge-podge; we have tests written in a variety of languages. I ported Test::Builder from Perl 6 to PIR a couple of years ago, and we've used it to test Parrot and some of the languages hosted on Parrot very successfully. (I first realized that Parrot's interoperability worked when I successfully called some of the multimethods defined in Test::More in PIR from Pheme, a Scheme-a-like language with no knowledge of multimethods.)

This weekend I ported Test::Class to PIR. It took a couple of hours. Actually, it took less than an hour to port the basics of Test::Class to PIR, and slightly over an hour to debug my proof of concept into code of sufficient quality to check in.

Perhaps my favorite part of Test::Class in Perl 5 is the use of subroutine attributes to specify the number of tests you'll run. Unfortunately for the port, PIR doesn't have subroutine attributes, so I wrote methods to add setup, startup, shutdown, teardown, and test methods to the test object. I'm not completely happy with the syntax, but it works.

Along the way, I fixed a bug I never knew existed in the PIR Test::Builder, which is nice -- I prefer to find and fix bugs before other people run across them (which is probably why people have assigned me the really tricky bugs in Parrot in recent months).

I did catch myself saying "You know, a declarative language for specifying tests in arbitrary source languages would be very useful". Mark my words. In the next five years, everyone reading this will be able to write their own little declarative languages which interoperate fully with other full-fledged languages.

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.
  • xUnit goodness spreading throughout the world!
  • Perhaps my favorite part of Test::Class in Perl 5 is the use of subroutine attributes to specify the number of tests you'll run.
    Why not always run them all? When are you going to specify X number of tests in a subroutine, but run less than the total?
    • I mean that you specify the number of tests in the method. It's an additional piece of metadata -- "This method runs five tests" -- rather than a directive -- "Only run five tests in this method, and then stop executing this method."

    • Or more precisely, “this method is expected to run 5 tests.” So if it runs fewer or more, you know something is wrong.