I didn't grow up in an era where testing was as well though of as it is now. When I learned to program, you ran a few tests after the fact and threw it over the wall to the QA department. Not very politically correct in today's software engineering world.

As a result, I understand the value of testing and support the idea intellectually, but I don't have the discipline.

Recently I was faced with the problem of building code that translated a domain specific language (KRL) back and forth between three different representations:

The textual representation is what people read and write. The JSON representation is what machines (other programs) will read and write. The abstract syntax (a Perl data structure) is what will be interpreted.

I quickly realized that getting this right--and convincing myself of that--would require something more than some ad hoc testing. So, I decided to mechanize.

I knew that Perl had testing facilities--anyone who's built a library has seen that. So, I had to figure out how they worked. I found these resources handy:

• Test::Tutorial - the basics
• An Introduction to Testing - some more advanced things, like Test::More that helped specifically with what I needed to do
• Automated testing with Perl
• Large Project Testing with Perl (PDF) - for the project stuff

Here's what I did:

• Wrote a collection of test programs in KRL. These can be expanded as needed, as I think of things to test.
• Built a test script for running each of those programs through a round trip through the parser and pretty printer. If the text matches (modulo whitespace) it's OK
• Built another test script for running each of these programs through a round trip all the way to the JSON representation and back.

I also added test scripts for each module in the system as well as a few scripts to check for developer issues--thanks to petdance (PDF).

I used the petdance smoke script to run all the tests in Test::Harness. I modified the petdance rule.t script to check for Perl programming best practices like always having use strict at the front of every Perl program in the collection.

I also wrote a use.t script that goes through the entire collection of Perl modules and programs, gathers a unique list of every library they use, and then checks for availability on the current machine.

Now, I can flesh out this framework with other tests as they come to me or I run into problems. It feels good.