Part I: Principles and Practices of Testing

Testing, in particular automated tests written in code, pervades software engineering. Whether through test-driven development, continuous integration, behavior-driven development, continuous delivery, acceptance test-driven development, specification by example, integration testing, system testing, or unit testing, everyone involved in software-based product development has a chance to write automated tests. Agile, Lean,¹ and software craftsmanship movements espouse high levels of testing to support rapid development and high quality.

1. I use Lean to refer to a Lean Production approach derived from the Lean Manufacturing movement as opposed to Lean Startup. The opinions about quality in this chapter apply to the sustainably productized software you need after you have learned what works from your Lean Startup experiments, if that is your business approach.

Thought leaders in software engineering promote code-based testing as an essential part of the professional developer’s repertoire. “Uncle Bob” Martin [CC08, CC11] espouses it for software craftsmanship. Gerard Meszaros [xTP] consolidates the lexicon around it. Steve Freeman and Nat Pryce [GOOS] describe how to grow your software with a healthy dose of testing. Michael Feathers [WEwLC] shows you how to rescue your old code through testing and even defines legacy code as code without tests. Kent Beck [XPE] and others tell you how to take your programming to the extreme, in part by using test-driven development.

Each of these luminaries describes an essential part of the use of testing in software development. Each of their works uses extensive examples to help you understand their particular teachings.

However, as I have coached teams into testing regimens, I have repeatedly found that the obstacle to adoption is neither a lack of understanding of the process flow, nor a misunderstanding of the concepts, nor an insufficient lexicon, nor skepticism about the value of the practices. All of these obstacles exist in various people at different times, but the most common one that has not been well addressed is simply limited understanding of the mechanics of testing code and of writing testable code.

While this book focuses on the mechanics—the implementation patterns—of programmatic testing and testability, you will apply the techniques more adroitly if you approach the book with an understanding of the conceptual framework that motivates it. Part I examines the relationship between engineering and craftsmanship and the role of testing in craftsmanship. It then shows you how to approach the testing of existing and unwritten code, how to better understand the intent of code, what testability looks like, and guiding principles to keep in mind as you write your tests.