Test Double
A generic term for any object that replaces a production dependency during testing, including dummies, fakes, stubs, spies, and mocks.
Also known as: Test Doubles, Test Stand-In
Category: Software Development
Tags: testing, software-engineering, patterns, quality
Explanation
A test double is a generic term, coined by Gerard Meszaros in his book xUnit Test Patterns, for any object that stands in for a real production dependency during testing. The name is an analogy to stunt doubles in filmmaking: just as a stunt double replaces an actor for dangerous scenes, a test double replaces a real component to make tests safer, faster, or more controllable.
Test doubles solve a fundamental problem in testing: how to test a unit of code in isolation when it depends on other components that are slow, unreliable, nondeterministic, or have side effects. By replacing these dependencies with controlled substitutes, developers can write tests that are fast, repeatable, and focused on the behavior of the code under test.
Meszaros identified five categories of test doubles, each serving a different purpose:
**Dummy objects** are passed around but never actually used. They exist only to fill parameter lists or satisfy type requirements. A null value or empty object often serves as a dummy.
**Fake objects** have working implementations that take shortcuts unsuitable for production. An in-memory database replacing a real database is a classic example. Fakes are functional but simplified.
**Stubs** provide canned answers to calls made during a test. They are pre-programmed to return specific values but do not respond to anything outside their programming. Stubs support state-based verification.
**Spies** are stubs that also record information about how they were called. They capture call counts, arguments, and invocation order, enabling verification of interactions after execution.
**Mocks** are pre-programmed with expectations about which calls they should receive. They verify that the code under test interacts correctly with its dependencies, throwing exceptions for unexpected calls. Mocks support behavior-based verification.
Martin Fowler distinguishes between two schools of testing based on test double usage: classical (or Detroit-school) testing, which uses real objects when possible and test doubles only when necessary (for slow or side-effecting dependencies), and mockist (or London-school) testing, which mocks all dependencies to isolate each unit completely. This distinction is explored in depth in Fowler's article 'Mocks Aren't Stubs'.
Modern testing frameworks like Mockito (Java), Jest (JavaScript), unittest.mock (Python), and Moq (.NET) provide built-in support for creating test doubles, blurring the lines between the categories. Most frameworks combine stub and spy capabilities into a single 'mock' construct, which can lead to confusion about the terminology.
Related Concepts
← Back to all concepts