Test Doubles Strategy

Test Doubles Strategy

Strategies for replacing real objects with test doubles.

Context

You are selecting the right test double for the job. Understand the tradeoffs of each approach.

Domain Context

• Stub: Returns canned answers; doesn't care how many times it's called
• Mock: Expects specific calls; verifies behavior
• Fake: Lightweight working implementation; slower but more realistic than stub
• Spy: Records calls; can verify and allow through to real object
• Dummy: Placeholder; passed but never used

Instructions

1. Stub: Use when you need predictable return values; database returning test data
2. Mock: Use when you need to verify that a dependency was called correctly
3. Fake: Use for database or third-party service; test containers are modern fakes
4. Spy: Use when you need both verification and real behavior
5. Dummy: Use when dependency is required by signature but not used
6. Avoid Over-Mocking: If everything is mocked, you're not testing integration
7. Prefer Fakes: Modern practice uses test containers over mocks for external services

Anti-Patterns

• Mocking everything; you need at least some real code to test
• Over-specifying mocks; brittle tests that fail on implementation changes
• Mocking your own code; mock external dependencies, not your logic
• Complex mock setup that's harder than the test; use factories or test builders
• Never testing error paths through mocks; ensure your error handling actually works

Further Reading

• Martin Fowler, Test Double essay
• Gerard Meszaros, xUnit Test Patterns