Another reason for TDD

It seems that one can never have enough good reasons for espousing Test Driven Development (TDD). If there is a dearth of cogency in this argument, then I hope the following helps.

One way to think about a robust test suite is that it is something akin to a safety net against creating unsafe software. The definition I have in mind is coincident with what Donald Norman calls a "forcing function", and is sometimes referred to as Poka-yoke.

Consider a kitchen appliance such as the food processor. To run the food processor, you must assemble the various parts in a precise way. Consider just the lid for the moment. Not only must you lock the lid in place; it must also unlock the hidden safety switch with the projecting cam (see figure).

If the cam is broken, then the food processor will not run, even if the lid fits snugly on the bowl. While it can be distressing if the cam breaks during washing the lid in the dishwasher; the cam provides a forcing function, preventing unsafe operation of the food processor.

TDD can be looked as a practice of providing a comprehensive forcing function for software. If the tests are broken, the software will not run (would not build in most cases). It can be vexing when the build breaks because of failing tests, but the tests prevent producing unsafe software.

So the next time someone complains about tests failing builds, politely ask them if they'd like to use a blender that ran with or without the lid.