Test doubles explained: mock vs. stub vs. fake vs. spy

A test double is any object that stands in for a real dependency so a test can run in isolation. The four you'll meet most often differ by what they actually do: a stub returns canned answers to calls, a fake is a lightweight but working implementation (like an in-memory database), a spy records how it was called so you can assert on it afterward, and a mock is pre-programmed with expectations and fails the test itself if the expected calls don't happen. Stubs and fakes help you verify state; spies and mocks help you verify behavior.

What is a test double?

"Test double" is the umbrella term coined by Gerard Meszaros in xUnit Test Patterns, by analogy with a stunt double who steps in for an actor. It covers five kinds of stand-in, ordered here from simplest to most demanding:

1. Dummy — an object passed around but never actually used, just to fill a required parameter.
2. Stub — returns hardcoded answers to the specific calls made during the test.
3. Fake — a real, simplified implementation with working logic that takes shortcuts unsuitable for production.
4. Spy — a stub that also records information about how it was called.
5. Mock — pre-programmed with expectations that form a specification of the calls it should receive, and can fail the test on its own.

Most day-to-day confusion is between the middle four. The single most useful distinction: stubs and fakes support state verification (you check the end result), while spies and mocks support behavior verification (you check that certain interactions happened).

Stub vs. mock: what is the actual difference?

This is the pair people mix up most. A stub is passive input; a mock is an active assertion.

• A stub exists to feed your code. If a function needs the current exchange rate, a stub returns 1.09 every time so the rest of the logic can run. Your assertions target the output the code produced, not the stub.
• A mock exists to check an interaction. If the contract says "on checkout, charge the payment gateway exactly once," a mock is told to expect one charge() call and will fail the test if that call never comes, comes twice, or comes with the wrong amount.

Rule of thumb: if you would still assert something without the double present, you probably want a stub. If the double is the assertion, you want a mock.

Fake vs. stub: when do you need a working implementation?

Reach for a fake when a stub's hardcoded answers can't keep up with the behavior your test exercises. A stub for a user repository might return the same record for every ID; the moment your test writes a record and expects to read it back, that stub breaks down. A fake — an in-memory implementation of the same interface — actually stores and retrieves data, so it holds up across a realistic sequence of calls while staying fast and free of external services.

Common fakes include in-memory databases, a fake clock you can advance by hand, and a fake mail server that captures messages instead of sending them. The tradeoff: a fake is more code to maintain and can drift from the real dependency, so it needs its own contract tests to stay honest.

Spy vs. mock: recording calls vs. setting expectations

Spies and mocks both watch interactions, but they differ in when they judge.

• A spy records calls silently and lets you assert on them after the fact: "the logger was called once, with a message containing 'timeout'." Nothing fails until your explicit assertion runs, which keeps the test readable and the failure message specific.
• A mock sets expectations up front and verifies them for you. This is stricter and can catch missing calls you'd forget to assert on, but over-strict mocks that pin down every internal call make tests brittle.

In practice, prefer a spy plus a targeted assertion when you care about one or two specific interactions, and reserve mocks for genuine contracts where an omitted call is itself a bug.

Which test double should I use?

Work from the cheapest option upward and stop at the first that proves your claim:

1. Use the real object when it's fast, deterministic, and side-effect-free. A double you don't need is just coupling you'll pay for later.
2. Use a stub when the code only needs a value to proceed and you'll assert on the result.
3. Use a fake when the interaction spans multiple calls with state, like read-after-write.
4. Use a spy when you must confirm a specific call happened but don't want up-front strictness.
5. Use a mock when a required interaction is part of the contract and its absence is a defect.

The anti-pattern to watch for is over-mocking: tests so tied to internal call sequences that any refactor turns them red even when behavior is unchanged. When a suite breaks constantly on safe refactors, the doubles — not the code — are usually the problem.

Test doubles and end-to-end testing

Doubles are indispensable for fast unit tests, but they share one blind spot: a double only knows the behavior you told it about. If the real dependency changes and your stub or mock doesn't, your tests stay green while production breaks — an escaped defect no amount of mocking would have caught. That's the case for a layer of tests that run against the real, assembled system.

This is where AutoSim fits: self-healing end-to-end tests that drive the actual application, so you get the honesty of real dependencies without hand-maintaining brittle selectors. Pair fast, well-chosen doubles at the unit level with real end-to-end coverage above them, and you catch both the logic bugs and the integration bugs. For more on keeping that top layer stable, see our guides on fixing flaky end-to-end tests and writing resilient test selectors, or browse the full Klavity blog.