Mocks, Stubs, and Fakes

By Michael Samuel Naeem · January 18, 2026 · 5 min read

The test verified that emailService.send() was called once. Production failed because the email body was wrong — nobody asserted content, only that the method fired. The mock passed; the user never received a password reset. Test doubles are tools; the failure mode is testing that your code talked to a fake instead of testing that your code works.

Gerard Meszaros cataloged test doubles — stubs, mocks, fakes, spies, dummies — and the vocabulary still matters because teams say "mock" when they mean "stub" and write brittle tests coupled to call counts.

Taxonomy

Stub example

PaymentGateway stub = id -> PaymentResult.success("txn-123");
OrderService service = new OrderService(stub, repo);
service.checkout(order);
assertThat(order.getStatus()).isEqualTo(PAID);

Stub enables test; assertion is on system under test state.

Mock example (Mockito)

@Mock PaymentGateway gateway;
@InjectMocks OrderService service;

@Test
void chargesOnCheckout() {
  when(gateway.charge(any())).thenReturn(success("txn-1"));
  service.checkout(order);
  verify(gateway, times(1)).charge(argThat(c -> c.amount() == 999));
}

Mock verifies interaction with collaborator. Useful when side effect is the outcome (send email, charge card) and return value alone is insufficient — but assert meaningful arguments, not just times(1).

Fake example

class FakeOrderRepo implements OrderRepository {
  private final Map<OrderId, Order> store = new HashMap<>();
  public void save(Order o) { store.put(o.id(), o); }
  public Optional<Order> find(OrderId id) { return Optional.ofNullable(store.get(id)); }
}

@Test
void persistsOrder() {
  FakeOrderRepo repo = new FakeOrderRepo();
  OrderService service = new OrderService(realGateway, repo);
  service.checkout(order);
  assertThat(repo.find(order.id())).isPresent();
}

Fake survives interface additions better than 50 mock setups — one fake class, many tests.

When to use what

External API (Stripe)     → Mock at unit boundary OR contract test + fake
Database                  → Fake repo unit tests; Testcontainers integration
Clock / random            → Stub/fixed Clock
Logger                    → Dummy or spy in rare cases
Complex collaborator      → Fake if reused; stub for one-off return

Mock overuse smells

• Test breaks when refactoring private method extraction — coupled to call path
• More mock setup lines than code under test
• verify on every method — testing implementation, not behavior
• Mocks return mocks (deep stub chains)

London vs Chicago school: London mocks collaborators at unit boundaries; Chicago uses real objects where practical and tests state. Modern consensus: Chicago-ish with selective mocks/fakes.

Spies — use sparingly

const spy = vi.spyOn(console, "error").mockImplementation(() => {});
// ... trigger error path
expect(spy).toHaveBeenCalledWith(expect.stringContaining("payment failed"));
spy.mockRestore();

Spies on real objects for cross-cutting concerns. Prefer injecting a Logger interface.

DI makes doubles swappable

Constructor injection:

class NotifyUser(private val mailer: Mailer, private val repo: UserRepo)

Tests pass FakeMailer; production passes SmtpMailer. No framework magic required.

Partial integration beats total mock

@MockBean ExternalCreditBureauClient  // slow, external
@Autowired OrderService              // real
@Autowired FakeOrderRepo configured  // @TestConfiguration

Spring test slice tests real wiring with one mocked boundary — catches bean misconfiguration unit tests miss.

Contract tests vs mocks at service boundaries

At HTTP boundaries, prefer contract tests or recorded interactions (VCR) over hand-written mocks that drift from OpenAPI. Mocks excel inside a service unit test; fakes and contract tests excel at the edge where schema changes propagate silently. Align with Pact or schema validation so doubles update when API evolves.

When to use each double

Prefer fakes over mocks for repository tests — mock-heavy tests break on refactor without behavior change.

Common production mistakes

Teams get test doubles mocks stubs wrong in predictable ways:

• Skipping failure-mode rehearsal — run a game day or fault injection exercise before peak traffic, not after the first outage.
• Missing correlation context — every error path should carry request, trace, or tenant identifiers so incidents are debuggable.
• Optimizing for demo, not steady state — load tests, cache warm-up, and cold-start paths matter more than local dev latency.
• Undocumented trade-offs — if you chose speed over strict correctness (or vice versa), write that down for the next engineer.

Testing strategy for test doubles mocks stubs gives false confidence when mocks return happy paths only, flakey tests are retried until green, and contract tests are never run against staging before deploy.

Debugging and triage workflow

When test doubles mocks stubs misbehaves in production, work top-down instead of guessing:

1. Confirm scope — one tenant, region, or deployment stage? Narrow blast radius before deep diving.
2. Check recent changes — deploys, flag flips, config pushes, and schema migrations in the last 24 hours.
3. Compare golden signals — latency, error rate, saturation, and traffic for the affected surface vs. baseline.
4. Reproduce minimally — smallest input or scenario that triggers the failure; capture traces/logs with correlation IDs.
5. Fix forward or rollback — if rollback is faster than root-cause during incident, rollback first, postmortem second.
6. Add a guard — alert, integration test, or circuit breaker so the same class of failure is caught earlier next time.

Document the timeline during triage. Future you (and on-call) will need timestamps, not just conclusions.

Metrics worth dashboarding

For test doubles mocks stubs, alert on symptoms users feel—not only infrastructure CPU:

Slice by version, region, and tenant during rollout. A flat global graph hides a bad canary.

Resources

• Mocks Aren't Stubs (Martin Fowler)
• Test Double (xUnit patterns)
• Mockito documentation
• Testcontainers
• Growing Object-Oriented Software, Guided by Tests