Key practice: Test Driven Development

Jason Yip
2 min readMay 6, 2023

Key practice in effective product development culture.

Test Driven Development:

  1. Write a single test first;
  2. Run the test to ensure it fails;
  3. Write just enough code to make the test pass;
  4. Refactor (see Kent Beck’s 4 rules of simple design) ;
  5. Repeat

This is often summarised as Red Green Refactor.

“Red”: 1. Write a single test first; 2. Run the test to ensure it fails. “Green”: 3. Write just enough code to make the test pass. “Refactor”: 4. Refactor
Red Green Refactor

Test First

“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)”

Kent Beck on Twitter

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.

See also:

--

--

Jason Yip

Senior Manager Product Engineering at Grainger. Extreme Programming, Agile, Lean guy. Ex-Spotify, ex-ThoughtWorks, ex-CruiseControl