TDD: Detroit vs London — what’s the difference?
Post by
Damian Sibiński
Published
3 February 2025
TTest-Driven Development has many flavours. The two most recognisable are the Detroit (classicist) and London (mockist) styles. The difference is not in the Red–Green–Refactor cycle itself, but in what we treat as the unit under test, how we handle dependencies, and how much we care about isolation.
In both styles you write a failing test first, then the minimal implementation, then refactor. The difference lies in the boundaries of the test and whether you prefer to test behaviour "inside" the class or the contract at its boundary.
Detroit: you test the outcome and behaviour of the object in isolation from real dependencies, but without mocks. London: you test collaboration with dependencies through interfaces and mocks.
Detroit style (classicist)
In Detroit you test one "unit" — usually a class — in isolation, but with real (or simple) collaborators where possible. You do not inject mocks; dependencies may be real (e.g. an in-memory database) or simple stubs. Tests verify state or the final result (e.g. return value, object state). Refactoring inside the class does not require changing tests — tests are coupled to behaviour, not implementation. This approach favours simplicity and fewer mocks, but tests can be slower and may touch several classes at once (the test acts as a "small integration" test).
London style (mockist)
In London you replace every dependency with a mock (or stub). The test verifies that your class called the expected methods on its dependencies with the expected arguments — you test interactions (the contract). The boundary of the test is a single class; everything "outside" is mocked. This gives strong isolation and fast tests, but tests become sensitive to how you call dependencies (e.g. changing the order or name of a method requires updating tests). It often pushes you to design interfaces up front for testability.
When Detroit, when London?
Detroit works well when dependencies are simple or you want to test a few objects together as a small system — e.g. domain logic, a service with an in-memory repository. London makes sense when there are many dependencies (API, database, queue, email) — you mock them and test orchestration. In practice many teams mix both: Detroit for domain logic, London for application layers (handlers, controllers). The important thing is to choose a style consciously and stick to it within a layer, so tests stay consistent and easy to maintain.
Loading comments…