We all pay lip service to testing code, but how many of us actually enjoy doing it? I certainly haven't, for most of my programming career. But now I find I'm acquiring a taste for it. Of course, I have also documented on this page a growing tolerance for sitting through meetings. Both may simply be signs of intellectual decay.Whatever the reason, I'm finding a definite shift in my personal tactics for producing decent computer code. Once upon a time, I prided myself on writing really good first drafts. My code didn't often work the first time, but once it got past the compiler and the obvious stupid cases, it usually worked pretty well in general. Those successes discouraged me from writing tedious test cases, however. As a result, my commercial offerings usually display a long tail of bug reports that are well short of disastrous, but still embarrassing. See "Standard C: Bugs," CUJ, September 1992, for the early history of my Standard C library, by way of example.
My major personal effort at testing the Standard C library was to write a smattering of "t-tests" — short programs with names such as tassert.c, tctype.c, etc. As you might guess, these each test the superficial behavior of one of the 15 Standard C headers. Over the years, I have been astonished at how often even these most cursory of tests have revealed bugs I introduced in the guise of improvements. My customers have also found them useful in migrating the code to new environments, even though that was hardly their original focus.
As a result, I've found myself devoting more and more time to making these t-tests into what they should have been in the first place. I'm making corresponding t-tests for the Standard C++ library I've written. I've even taken the time to produce far more extensive tests for the float and long double math functions I've had to add to the lot.
What I've learned to date is that every bit of testing you do pays off with compound interest. You find bugs and infelicities earlier and more often. Even better, having a good test harness helps you debug enhancements that much faster. Of course we all know all this — I've charged people good money to lecture them on the subject — but there's nothing like occasional reinforcement to drive the message home.
My biggest problem now is not that I find writing test code boring. Rather, I have trouble finding the time to write all the test code I'd like to have. That's a sure sign of maturity, or senility, but I don't know which.
P.J. Plauger
pjp@plauger.com