Lessons and processes from building construction, physical goods manufacturing, and other engineering disciplines are often misapplied to software creation. Nevertheless, these disciplines occasionally provide very useful analogies. One of these is the idea that a given design must accommodate more than just functional and aesthetic needs.
For example, designers of physical goods must consider how much it will cost to actually build what they're designing. The costs to procure materials, tool-up a factory, and train an army of workers are a major portion of the costs to market a physical good. Want to design a car you can sell for $20k? Skip the Italian leather seats. Forget about the brand-new, high-compression engine that would double factory tooling costs. Drop the independent rear-suspension.
One good thing about design-related manufacturing costs is that they are well-understood and naturally visible. They may be miscalculated, but there's little chance they'll be forgotten or ignored. This is not true in the software world. Instead, the cost implications of many design choices are invisible even to the designer—let alone the rest of the organization. One of these is the recurring cost to validate functionality as the software changes. When validation is 100% manual (meaning a person—whether a QA tester or developer—must explicitly execute and review the results of each test case) it becomes extremely expensive (in terms of time as well as money). (Not to mention that top-down, manual validation is simply too inefficient to exercise more than a small fraction of possible code paths and thus will allow many code defects to escape into the wild.)
We need ways to expose design-related validation costs early in the development cycle so they can be properly accounted for when planning and choosing features—and so the design can be altered when necessary to reduce those costs. We also need ways to minimize validation costs so our software can be tested thoroughly and still be profitably sold and supported.
Rigorous automated unit testing helps us both expose design-related validation costs and minimize those costs:
- It exposes validation costs because we're forced to invest labor in creating automated tests at the time a feature is added or created, incorporating more of the long-term costs of the feature into the initial implementation schedule.
- It minimizes validation costs because the labor invested in test creation returns benefits each time the software is modified for an indefinite period of time and dramatically reduces total validation costs.
Automated unit testing forces validation costs to become a first-class design consideration: designs that are not unit-testable are failed designs and must be replaced by designs that are unit-testable and still meet functional and performance goals.
Rigorous unit testing should change our mindset toward one of designing for testability. With this mindset we should
- Focus the same level of energy and creativity on the design of our unit tests as on the components being tested.
- Take the same care in organizing and maintaining our test code and projects as we take with the rest of our codebase
- Believe that a software feature is inseparable from its unit tests.
- Alter our designs as necessary to support unit testing in both personal and automated build environments
