Key practice in effective product development culture.
- Write a single test first;
- Run the test to ensure it fails;
- Write just enough code to make the test pass;
- Refactor (see Kent Beck’s 4 rules of simple design) ;
This is often summarised as Red Green Refactor.
“TDD is test-first + one test at a time + just-in-time structure & behavior (only enough logic to pass the tests, only enough structure to help write the logic)”
Test Driven Development doesn’t mean tests written shortly after coding OR just “developer testing”.
Test First means code is designed to be testable as a primary concern.
Test First means the tests tend not to be coupled to the implementation.
Detroit-style vs London-style.
Two different styles have developed around Test Driven Development:
- “Classical”, “Detroit”, “Chicago” style
- “Mockist”, “London” style
“The classical TDD style is to use real objects if possible and a double if it’s awkward to use the real thing… A mockist TDD practitioner, however, will always use a mock for any object with interesting behavior.”
“Mocks Aren’t Stubs” by Martin Fowler
I describe the distinction as whether you start with the essence of the domain and evolve (Detroit-style) OR start with the customer interface to pull what is needed (London-style).
I generally prefer the Detroit-style but I also think it depends on the type of problem you’re working on.
- Test Driven Development by Example by Kent Beck
- Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce
- Testing Without Mocks: A Pattern Language by James Shore
- Michael “GeePaw” Hill’s content on TDD
- Beware the Integration Tests Scam series by J.B. Rainsberger. He also wrote a book: JUnit Recipes: Practical Methods for Programmer Testing