Mocks vs Stubs are both used in unit testing to simulate dependencies, but they serve different roles. Stubs provide fixed responses, while mocks focus on verifying interactions.
- Stubs: Return predefined data and do not care how they are used; used for controlling test inputs.
- Mocks: Verify behavior and interactions, such as whether a method was called with correct arguments.
- Purpose difference: Stubs support state testing, while mocks support behavior testing.
Test Doubles
Test Doubles are simplified replacement objects used in unit testing to simulate real dependencies. They help isolate the code under test by replacing external components like APIs, databases, or services.
- Isolation: Remove dependency on real external systems during testing.
- Simulation: Mimic real components with controlled behavior or data.
- Types: Include mocks, stubs, fakes, and spies depending on testing needs.
Stub
A Stub is a type of test double used in unit testing that provides predefined (fixed) responses to method calls. It replaces real components so you can test a piece of code in isolation without relying on actual external systems.
- Predefined output: Returns fixed data regardless of input or logic.
- No behavior verification: Does not check how it is used in the test.
- Used for isolation: Helps test code without real databases, APIs, or services.
Top-Down Testing using Driver, Module and Stubs
This diagram represents a Top-Down Integration Testing approach where a main program (driver) tests a module by replacing lower-level components with stubs.

In this testing approach, the Driver or Main Program acts as the starting point that calls the Module under test. The module may depend on other sub-modules, but instead of using real components, stubs are used to simulate their behavior. These stubs provide predefined responses so that testing of the main module can be done independently.
This helps in testing higher-level modules early in the development process without waiting for all dependent components to be fully developed.
Mock
A mock is a test double used in software testing to simulate real objects and verify how they are used. It is mainly used to check interactions between different parts of a program.
- Mocks simulate real objects and their behavior during testing
- They verify method calls, parameters, and interactions
- Used to ensure components in a system are working together correctly
Mock-Based Testing Architecture in API Systems
This architecture shows how real external systems are replaced with mock versions so the main component can be tested independently and safely.

This diagram shows how a testing framework interacts with a software component using APIs while replacing external dependencies with mock systems.
At the left side, a Testing Tool/Framework sends requests through an API to the main Component under test. This component represents the actual application logic being tested.
However, instead of communicating with real external systems, the component connects to mocked services:
- Mock Legacy System: Simulates older or existing enterprise systems
- Mock Peer Services: Simulates other internal microservices or modules
- Mock 3rd Party Components: Simulates external services like payment gateways, email providers, or cloud APIs
Stub vs Mock
Below are the differences between stub and mock:
| Feature | Stub | Mock |
|---|---|---|
| Definition | A stub is a dummy object that provides predefined responses to method calls. | A mock is an object that simulates real behavior and also verifies interactions. |
| Purpose | Used for state verification (returns fixed data). | Used for behavior verification (checks method calls). |
| Behavior | Simple and passive (just returns data). | Smart and active (records and verifies calls). |
| Usage | Used when you want to control test inputs. | Used when you want to test interactions between objects. |
| Validation | Does not verify how it was called. | Verifies method calls, parameters, and call count. |
| Created by | Often manually created or simple test doubles. | Usually created using frameworks like Mockito, JMock, WireMock. |
| Complexity | Simple | More complex |
| Example use case | Returning fake data from a database call. | Checking if a service method was called once with correct arguments. |