A test double is an object that looks and behaves like a production dependency but is simplified to reduce complexity during testing. Replacing dependencies can isolate a system under test, narrow the source of failures, and split a complicated object graph into manageable pieces. section 2.1
Test doubles cover several roles, grouped into two behavioral types:
- Mocks and spies emulate and examine outgoing interactions: calls that change a dependency’s state. section 5.5
- Stubs supply incoming interaction data without representing the final result. section 5.5
- Dummies and fakes serve the same broad role as stubs; a mocking library can create either mocks or stubs. section 5.5
The isolation strategy is a trade-off. The London style replaces mutable collaborators, usually treating a class as the unit under test. The classical style replaces dependencies shared between tests and verifies a unit of behavior, which may span several classes. Immutable values can remain real in either approach. section 2.2 section 2.5
Prefer observable behavior over implementation details. Verifying that a command was called can couple a test to an intermediate interaction rather than the resulting behavior, making the test fragile under refactoring. Test doubles help with difficult dependencies, but they do not repair a design that is hard to test. section 5.5 section 2.5
Purchasing inventory
A classical test creates a real store, adds ten shampoos, and checks that purchasing five succeeds while inventory falls to five. A London-style test replaces the store with a mock, configures HasEnoughInventory to return true, and verifies that RemoveInventory is called once. For an insufficient-inventory case, it configures false and verifies that removal never occurs. The first emphasizes resulting state; the second emphasizes collaborator interaction.
