Test doubles

Test doubles

A test double replaces a real dependency the test cannot afford: a payment gateway, a system clock, a database round trip. The trap is reaching for a mock by reflex and asserting that a method was called, which pins the code's internal wiring rather than its result. Such tests fail on every refactor that keeps behavior intact, and they pass while behavior is quietly broken. Pick the double that matches what you actually need to control.

Method

1. Name the double you mean. A stub returns canned answers, a fake is a working lightweight implementation such as an in-memory repository, a mock records calls for later verification, a spy wraps a real object to observe it. Loose talk of "mock everything" hides which of these the test needs.
2. Default to state verification. Drive the system through the double, then assert on the returned value or resulting state: assert account.balance == 40. This survives any refactor that preserves the outcome, which is the entire reason the test exists.
3. Reserve mocks for interaction that is the behavior. Verify a call only when the call is itself the observable effect: an email was sent, an event was published, a card was charged. verify(gateway).charge(500) is right when charging is what the code exists to do.
4. Prefer a fake to a pile of stubs. For a repository or clock, one small in-memory fake reused across tests reads cleaner than restubbing each method per test, and it catches sequencing bugs a lone stub cannot.
5. Only double what you own or what hurts. Wrap a third-party SDK behind your own interface and fake that, instead of mocking the vendor's types. Doubling a type you do not control freezes assumptions the next version breaks.
6. Keep doubles honest with a contract test. A fake that drifts from the real dependency yields false green. Run one shared suite against both the fake and the real implementation so their behavior stays aligned.

Checks

• If you renamed a private method without changing behavior, would this test still pass?
• Does each mock verification match an effect a user or another system can observe?
• Do several doubles in one test signal a unit with too many collaborators to isolate cleanly?

Boundaries

This is about choosing and placing doubles, not about seam design or the real-dependency end of the scale: defer wiring seams to integration-testing and library choice to the project. Mocking frameworks vary, so follow the one already in the suite.