The Productive Programmer

Chapter 6. Test-Driven Design

Unit testing is well established as a beneficial code-hygiene practice. Tested code provides greater confidence that the intent matches the result. Test-driven development (TDD) goes even further, insisting that you write tests before you write the code. When comparing software “engineering” to other engineering disciplines (which always requires a good handful of tortured metaphors), major differences pop up. We don’t have centuries of mathematics to rely upon in software. The science of software development hasn’t been around long enough (and we may never get to that level of sophistication). We also can’t take advantage of the economy of scale in traditional engineering. For example, the Golden Gate Bridge contains more than 1,000,000 rivets. You can bet that the engineers who designed that bridge knew the stress characteristics of those rivets and used that number multiplied by 1,000,000 to tell them important things about the stress on the bridge. A piece of software may also have 1,000,000 pieces, but they are all different. We can’t take advantage of the scale and multiplicity that “regular” engineers can. But developers do have an advantage: we can manufacture our components very easily and write code that verifies our components do what we intended them to do. Because it is vanishingly cheap to write software to test software, we can apply our ...