# Test Doubles Strategy

> Choosing between mocks, stubs, fakes, spies, and dummies based on testing needs.

- Skill: `sethdford/test-doubles-strategy` (Agent Skill)
- Install (CLI): `npx skillmds@latest add sethdford/test-doubles-strategy`
- Raw SKILL.md: https://api.skillmd.com/api/skills/sethdford/test-doubles-strategy/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: sethdford (https://skillmd.com/u/sethdford)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/sethdford/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_