Setup

You’ve learned the core fundamentals of TDD, from mechanics to preferred practices to techniques for dealing with dependencies. You’ve also refactored along the way, incrementally shaping your code with each change—but to what end?

The primary reason to practice TDD is to support the ability to add or change features at a sustained, stable maintenance cost. TDD provides this support by letting you continually refine the design as you drive changes into your system. The tests produced by practicing TDD demonstrate that your system logic behaves as expected, which allows you to clean up new code as soon as you add it. The implication is momentous. Without TDD, you don’t have the rapid feedback to allow you to safely and easily make incremental code changes. Without making incremental code changes, your codebase will steadily degrade.

In this chapter, you’ll learn what sorts of things you want to do when in the refactoring step. We’ll focus primarily on Kent Beck’s concept of simple design (see Extreme Programming Explained: Embrace Change [Bec00]), a great starter set of rules for keeping your code clean.