Testing Is the Engineering Rigor of Software Development
Neal Ford
DEVELOPERS LOVE TO USE TORTURED METAPHORS when trying to explain what it is they do to family members, spouses, and other nontechies. We fre- quently resort to bridge building and other “hard” engineering disciplines. All these metaphors fall down quickly, though, when you start trying to push them too hard. It turns out that software development is not like many of the “hard” engineering disciplines in lots of important ways.
Compared to “hard” engineering, the software development world is at about the same place the bridge builders were when the common strategy was to build a bridge and then roll something heavy over it. If it stayed up, it was a good bridge. If not, well, time to go back to the drawing board. Over the past few thousand years, engineers have developed mathematics and physics they can use for a structural solution without having to build it to see what it does. We don’t have anything like that in software, and perhaps never will because software is in fact very different. For a deep-dive exploration of the comparison between software “engineering” and regular engineering, “What is Software Design?”, written by Jack Reeves in C++ Journal in 1992, is a clas- sic.* Even though it was written almost two decades ago, it is still remarkably accurate. Reeves painted a gloomy picture in this comparison, but the thing that was missing in 1992 was a strong testing ethos for software.
* http://www.developerdotstar.com/mag/articles/reeves_design.html
166 97 Things Every Programmer Should Know

Testing “hard” things is tough because you have to build them to test them, which discourages speculative building just to see what will happen. But the building process in software is ridiculously cheap. We’ve developed an entire ecosystem of tools that make it easy to do just that: unit testing, mock objects, test harnesses, and lots of other stuff. Other engineers would love to be able to build something and test it under realistic conditions. As software devel- opers, we should embrace testing as the primary (but not the only) verifica- tion mechanism for software. Rather than waiting for some sort of calculus for software, we already have the tools at our disposal to ensure good engineering practices. Viewed in this light, we now have ammunition against managers who tell us “we don’t have time to test.” A bridge builder would never hear from his boss, “Don’t bother doing structural analysis on that building—we have a tight deadline.” The recognition that testing is indeed the path to repro- ducibility and quality in software allows us as developers to push back on arguments against it as professionally irresponsible.
Testing takes time, just like structural analysis takes time. Both activities ensure the quality of the end product. It’s time for software developers to take up the mantle of responsibility for what they produce. Testing alone isn’t sufficient, but it is necessary. Testing is the engineering rigor of software development.