7 Designing for testability

I usually say that every software system can be tested. However, some systems are more testable than others. Imagine that for a single test case, we need to set up three different web services, create five different files in different folders, and put the database in a specific state. After all that, we exercise the feature under test and, to assert the correct behavior, again need to see if the three web services were invoked, the five files were consumed correctly, and the database is now in a different state. All those steps are doable. But couldn’t this process be simpler?

Software systems are sometimes not ready for or designed to be tested. In this chapter, we discuss some of the main ideas behind systems that have high testability. Testability is how easy it is to write automated tests for the system, class, or method under test. In chapter 6, we saw that by allowing dependencies to be injected, we could stub the dependency. This chapter is about other strategies you can use to make testing easier.

7.1 Separating infrastructure code from domain code

7.2 Dependency injection and controllability

7.3 Making your classes and methods observable

7.3.1 Example 1: Introducing methods to facilitate assertions

7.3.2 Example 2: Observing the behavior of void methods

7.4 Dependency via class constructor or value via method parameter?

7.5 Designing for testability in the real world

7.5.1 The cohesion of the class under test

7.5.2 The coupling of the class under test

7.5.3 Complex conditions and testability

7.5.4 Private methods and testability

7.5.5 Static methods, singletons, and testability

7.5.6 The Hexagonal Architecture and mocks as a design technique

7.5.7 Further reading about designing for testability

Exercises