Chapter 1. The big picture
I can stand brute force, but brute reason is quite unbearable.
Oscar Wilde
“Only ever write code to fix a failing test.” That’s test-driven development, or TDD,[1] in one sentence. First we write a test, then we write code to make the test pass. Then we find the best possible design for what we have, relying on the existing tests to keep us from breaking things while we’re at it. This approach to building software encourages good design, produces testable code, and keeps us away from over-engineering our systems because of flawed assumptions. And all of this is accomplished by the simple act of driving our design each step of the way with executable tests that move us toward the final implementation.
1 The acronym TDD is sometimes expanded to Test-Driven Design. Another commonly used term for what we refer to as TDD is Test-First Programming. They’re just different names for the same thing.
This book is about learning to take those small steps. Throughout the chapters, we’ll learn the principles and intricacies of TDD, we’ll learn to develop Java and Enterprise Java applications with TDD, and we’ll learn to drive our overall development process with an extension to the core idea of TDD with what we call acceptance test-driven development (acceptance TDD or ATDD). We will drive development on the feature level by writing functional or acceptance tests for a feature before implementing the feature with TDD.