OSCON 3.6: Practical Perl Testing

(Auggghhh! The original version of this entry was lost due to system crash. I'm recreating it here, but it may have lost something. Or it may not have had it to start out with, we'll never know.)

Practical Perl testing was an odd session, with four instructors taking two session timeslots to deal somewhat randomly with various topics relating to Perl testing. Meanwhile MJD (in barefoot mode) lay on the floor chatting with Schwern and interrupted at random.

During the course of the rambling talk, they recommended several helpful modules:

Test::Differences

Use eq_or_diff instead of is_deeply to get better display of data structure differences

Test::LongString

Show shorter and hopefully more helpful failure messages when very long strings don't compare equal; several people pointed out that this module fell short of what it should have done

Test::Deep

Very flexible deep comparison of data structures

Test::Harness::Straps

Allow you to create your own testing harness; heavily work in progress right now

Test::Exception and Test::Warnings

Test for thrown exceptions and warnings (or lack thereof)

WWW::Mechanize

Great gobs of sugary user agent goodness; greatly aids in testing and automating web site interactions

HTML::Lint

Check for HTML errors in strings or files; also includes Test::More style wrapper and weblint CLI tool

Test::HTML::Content

Flexibly compare HTML source against desired structure

Devel::Cover

Make sure tests are actually exercising all existing code paths

Test::Lectrotest

Specification-based automated boundary condition tests

Along the way, they recommended a couple good books: Sean M. Burke's Perl & LWP and a Java testing book whose title I have clearly written down incorrectly, as searching for it is bringing up no obvious matches. Sigh.

The Java book recommended a testing mnemonic called "Right BICEP", which roughly stands for:

Right: Correct output with normal inputs
B: Boundary conditions, random parameters, etc.
I: Inverse relationship (didn't quite catch the details on this one)
C: Cross-check using a different algorithm
E: Error handling tests
P: Performance within reasonable bounds, and not suddenly worse after a change

Finally, MJD asked about doing test-first development when you're unclear on the form that your app will eventually take. The most common suggestion was to write an exploratory mockup, write a full set of tests for it, comment out the entire mockup, and start uncommenting and fixing the mockup until the tests are happy again.

Geoff Broadwell lives not far from O'Reilly headquarters in Santa Rosa, California, with a wonderful wife and daughter and four extremely spoiled cats. Geoff happily calls Perl the only computer language he ever really loved, having sampled a fair number before and since. He is on a personal mission to prove that dynamic languages are by far the best programming option for almost every purpose, and believes that the ultimate Linux distro of the future will contain little more than a kernel, an OpenGL and X server, the Parrot VM, and many, many Perl scripts.

oreillynet.com Copyright © 2006 O'Reilly Media, Inc.