Test doubles: stubs, mocks, fakes and when to use which

What it is

Fowler, following Gerard Meszaros, distinguishes dummies (passed but never used), fakes (working implementations with shortcuts, such as an in-memory repository), stubs (canned answers), spies (stubs that record how they were called) and mocks (objects pre-programmed with expectations that are verified after the action).

Why it matters

The choice decides what a test asserts. State-based tests with stubs or fakes check outcomes; interaction-based tests with mocks check that specific calls happened. Interaction tests break whenever the implementation changes its collaboration pattern, even when behaviour is unchanged.

How to apply

• Prefer real collaborators when they are fast and deterministic.
• Use fakes for infrastructure (clock, storage, message bus) so that behaviour stays testable without the real service.
• Use stubs for inputs from collaborators you do not control.
• Use mocks only where the interaction itself is the requirement (for example, "sends exactly one notification").
• Keep doubles behind the same interface as the real thing and test the fake against the real implementation occasionally.

Pitfalls

A test that constructs five mocks to exercise one method is testing wiring, not behaviour. Auto-mocking frameworks make it easy to stub methods that do not exist. Doubles for external APIs drift from reality; contract tests against the real API catch that.