Chapter 11. Design and testability
This chapter covers
- Benefiting from testability design goals
- Weighing pros and cons of designing for testability
- Tackling hard-to-test design
Changing the design of your code so that it’s more easily testable is a controversial issue for some developers. This chapter will cover the basic concepts and techniques for designing for testability. We’ll also look at the pros and cons of doing so and when it’s appropriate.
First, though, let’s consider why you would need to design for testability in the first place.
The question is a legitimate one. When designing software, you learn to think about what the software should accomplish and what the results will be for the end user of the system. But tests against your software are yet another type of user. That user has strict demands for your software, but they all stem from one mechanical request: testability. That request can influence the design of your software in various ways, mostly for the better.
In a testable design, each logical piece of code (loops, ifs, switches, and so on) should be easy and quick to write a unit test against, one that demonstrates these properties:
- Runs fast
- Is isolated, meaning it can run independently or as part of a group of tests, and can run before or after any other test
- Requires no external configuration
- Provides a consistent pass/fail result