Learning Perl Objects, References, and Modules

Chapter 14. Essential Testing

As briefly described in Chapter 13, a distribution contains a testing facility invoked from make test. This testing facility permits a module author to write and run tests during development and maintenance and the ultimate module installer to verify that the module works in the new environment.

Why have tests during development? One emerging school of thought states that the tests should be written first, even before the module is created, as a reflection of the module’s specification. Of course, the initial test run against the unwritten module will show nearly complete failure. However, as functionality is added, proper functionality is verified immediately. (It’s also handy to invoke the tests frequently as you code to make sure you’re getting closer to the goal, not breaking more things.)

Certainly, errors may be found in the test suite. However, the defect rate for tests are usually far lower than the defect rate for complex module code; if a test fails, it’s usually a good indication that there’s more work to be done.

But even when Version 1.0 of the module is finally shipped, there’s no need to abandon the test suite. Unless You code the mythical “bug-free module,” there will be bug reports. Each bug report can (and should) be turned into a test.^[92] While fixing the bug, the remaining tests prevent regression to a less functional version of the code—hence the name regression testing.

Then there’s always the 1.1 or 2.0 releases to think about. ...