A Word on Design Paradigms

I make many of the points in this chapter in the context of object-oriented (OO) design, which is the dominant design paradigm at the time of this writing and for the prior two decades. The issues I bring up here are not unique to OO. If anything, the variety of encapsulation mechanisms available in most OO languages give you a wider range of solutions to the problems I am highlighting. On the other hand, the number of mechanisms and the conventional wisdom that typically go with those mechanisms provide many ways to make code difficult to test or untestable.

As our industry matures, the general attitude toward testing is changing dramatically. The ready and continuingly increasing availability of computing power makes it an easy decision to run automated tests continuously. Lean-inspired approaches like extreme programming and practices like test-driven development push us to write our tests first to build quality in and to drive our designs. The ubiquity of software in our society increases the need to test software extensively and quickly.

However, our design paradigms and the programming languages that implement them have not kept up. We need to understand the limits of our design approaches in a world in which software is more important than ever before and software quality is a business decision. Whether you are working in a procedural, functional, or object-oriented frame, you need to consider testability as a design factor.