Testing: by Evelyn Mitchell

The 17th century German philosopher and poet Novalis said, "Most marriages are divorces." Had he been a software developer, he might have said, "Most programming is maintenance." Still, with careful testing from the outset, the maintenance of existing programs can be made much easier, but only if the effort of writing and running tests is justified.

Unit testing is the process of testing code as you write it. You can also use unit testing during regression testing, in which you determine if a program is working the way it did before you modified it. Unit testing is also known as "white box" or "glass box testing," as opposed to "black box testing."

Black box testing is, roughly speaking, testing done by someone who does not have access to the program's code. In black box testing the program is viewed (you might have guessed) as a black box that takes inputs and produces outputs, but doesn't reveal its internal structure. By contrast, unit testing exercises your full knowledge of the code by testing the interfaces to other code components and to user space, as well as the implementation.

Unit testing fully tests every interesting function a program performs. You can test for unusual data, or for combinations of values that should always or must never occur. You can even use it for coverage testing, to make sure that you've exercised every path through a program.

You can write the unit tests once you understand what you want a module to do, even before you've actually written the module. Kent Beck (author of Test Infected: Programmers Love Writing Tests -- see Resources) recommends writing the tests before you write the code because they can help to clarify your understanding of what the module is supposed to do independent of how it will do it, thereby separating design testing from implementation testing. If you can't write a test for a module before you write the module, that may suggest that you do not understand the design, or that the design has an error. If you can catch a design error at this stage, you've just saved yourself some coding time.

A unit testing framework, such as PythonUnit, makes it easy to test your code after every change, no matter how trivial. I work with multiple windows open -- one for the code I'm editing, one for the testing -- and I pop back and forth as I make changes.

This makes finding errors simpler because you know that the change you just made caused your test to fail. Frequent testing can eliminate those multi-hour debugging sessions where your code gets filled with print statements while you try to find that good line gone bad.

Writing all those test cases may seem like a lot of work, but I find it to be a very effective way of learning how a new piece of code functions (or doesn't function the way I thought it did). The time I spend writing tests is time I would have spent guessing about how something works, to no good end.

The simple fact is that the earlier you find a bug and fix it, the cheaper the fix is.