Test Double

A Dummy is the simplest form of test double. It is an object passed to the system under test but never actually used. Its sole purpose is to satisfy a method's parameter list.

• Purpose: To fill mandatory parameters where the actual value is irrelevant to the test.
• Characteristics: Often null, an empty object, or a primitive default value.
• Example: Passing a null User object to a method when testing a Logger class that doesn't interact with the user data.

A Stub provides canned answers to calls made during the test. It is programmed to return specific, hard-coded data in response to method calls, overriding the real dependency's behavior.

• Purpose: To control the indirect inputs to the system under test.
• Characteristics: Contains no logic; returns predefined data. Does not respond to anything outside its programmed responses.
• Example: A stub for a WeatherService that always returns "Sunny" to test how a TripPlanner behaves under good weather conditions.

A Spy is a type of stub that also records information about how it was called. It captures invocation details such as the number of calls, arguments passed, and the order of calls for later verification by the test.

• Purpose: To observe and make assertions about the interactions between the system under test and its dependencies.
• Characteristics: Passively records activity. Can also stub return values if needed.
• Example: A spy on an EmailSender to verify that the send() method was called exactly once with a specific recipient address after a user registration.

A Mock is an object pre-programmed with expectations about the calls it will receive. It verifies that these expected interactions occur. A test using a mock will fail if the expected calls are not made or are made in the wrong order.

• Purpose: To test the behavior (the outgoing commands) of the system under test.
• Characteristics: Defined by expectations set before the test executes. Verifies those expectations afterward. Often created using a mocking framework (e.g., Mockito, unittest.mock).
• Example: A mock PaymentGateway that expects a charge(amount, card) call with specific arguments. The test asserts this interaction happened.

A Fake is a working, but simplified and lightweight, implementation of a dependency. It has functional behavior but uses shortcuts unsuitable for production, such as an in-memory database instead of a real SQL database.

• Purpose: To replace a heavyweight, slow, or complex dependency with a functional equivalent that is good enough for testing.
• Characteristics: Contains real business logic but uses simplified infrastructure. It is not a stub—it has real, working internals.
• Example: A FakeUserRepository that stores users in a HashMap instead of a PostgreSQL database, allowing for fast, isolated data layer tests.

Selecting the appropriate test double is critical for clear, maintainable tests. Follow this guideline:

• Use a Dummy for unused required parameters.
• Use a Stub to force the system down a specific path (control inputs).
• Use a Spy to query how a dependency was used after the fact.
• Use a Mock to define and verify specific behavioral expectations.
• Use a Fake to replace a complex infrastructure component with a functional, test-friendly version.

Key Principle: Prefer stubs and fakes over mocks when possible, as they test state over interaction, leading to less brittle tests.

A mock is a test double that verifies interactions by recording and asserting that specific methods were called with expected arguments. It is programmed with expectations about how the unit under test will interact with it.

• Primary Use: Behavior verification.
• Key Trait: Fails the test if expected calls are not made or are made incorrectly.
• Example: In API testing, a mock HTTP client would verify that POST /users was called exactly once with a specific JSON payload.

A stub is a test double that provides predefined, canned responses to calls made during the test. It replaces a real component to control the test's indirect inputs.

• Primary Use: State control.
• Key Trait: Returns fixed data without verifying how it was called.
• Example: A stub for a payment gateway API always returns {"status": "success"} to test the happy path of a checkout function, regardless of the input amount.

A fake is a simplified, functional implementation of a dependency that is unsuitable for production but useful for testing. It has working business logic but uses shortcuts.

• Primary Use: Functional replacement.
• Key Trait: Provides actual behavior (e.g., in-memory storage) but with limitations.
• Example: An in-memory database or a lightweight email service that writes to a local log file instead of sending real SMTP packets.

A spy is a test double that passively records interactions (method calls, arguments) for later inspection by the test. It wraps a real object or another double.

• Primary Use: Interaction recording.
• Key Trait: Allows verification after execution, without enforcing expectations upfront.
• Example: A spy on a logging service captures all log() calls and their severity levels, allowing the test to assert that an error was logged after a specific API failure.

A dummy is a test double passed to satisfy a parameter list but is never actually used. It is often a null, 0, or an empty object.

• Primary Use: Parameter filling.
• Key Trait: No implementation; any call to it is outside the test's scope and may throw an exception.
• Example: Passing an unused HttpContext object to a controller method when testing only the request parsing logic.