liveBook · Manning

London school

As explained in Unit Testing Principles, Practices, and Patterns

The London school is a unit-testing approach that isolates the unit under test from its collaborator objects, typically with test doubles.

The London school is a unit-testing approach that isolates the unit under test from its collaborators. A class is treated as the unit, and mutable dependencies are replaced with test doubles so the class can be verified separately from external influence. section 2.1 section 2.5

Its defining choices are:

  • Isolate units rather than merely isolating tests from one another. section 2.2
  • Treat a class as the unit under test. section 2.2
  • Replace all mutable dependencies with test doubles, while retaining immutable values such as enums and numbers. section 2.2
  • Prefer communication-based testing, using mocks to verify interactions with collaborators. section 6.6

Customer purchase with a mocked store

A purchase test creates a mock IStore, configures HasEnoughInventory(Product.Shampoo, 5) to return true, and verifies that RemoveInventory(Product.Shampoo, 5) occurs once. A failure case returns false and verifies that removal never occurs. The real Product value remains because it is immutable. section 2.1 section 2.2

Figure 2.1. Replacing the dependencies of the system under test with test doubles allows you to focus on verifying the system under test exclusively, as well as split the otherwise large interconnected object graph.

Use the figure to see how replacing collaborators with test doubles reduces an interconnected object graph to the system under test and its focused tests. section 2.1

The approach offers fine-grained tests, easier testing of interconnected classes, and clearer fault localization after failure. Its main cost is over-specification: mocks can couple tests to implementation details, reduce resistance to refactoring, and make tests fragile. Communication checks are strongest when they cross an application boundary and have externally visible side effects. section 2.3 section 5.4 section 6.6

How Unit Testing Principles, Practices, and Patterns covers it

How deep it goes
Defines isolation, unit size, and dependency treatment, then demonstrates mocks and contrasts their fragility with classical testing.
Examples
Uses C# purchase tests with Customer, Store, IStore, Product.Shampoo, configured mocks, and interaction verification.
What it assumes
Assumes basic unit-testing knowledge and object-oriented dependencies; defines test doubles, mutable dependencies, and immutable values.
What you can do after
Evaluate isolation strategies and write class-focused tests with test doubles while recognizing coupling to implementation details.
How it connects
Connects unit testing with test doubles, mocks, classical testing, integration testing, implementation details, and test fragility.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Unit Testing Principles, Practices, and Patterns. The section links point to the parts of the book it draws on.