The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Mocking is a way to test a unit of software using a controlled substitute for one of its real collaborators. In the precise vocabulary used here, a mock is a test double configured with expectations about interactions; the test passes or fails based on whether the code makes those expected calls. That differs from a stub, which supplies prepared answers, and from other test doubles such as fakes and spies.
What is mocking in unit testing?
A unit under test may depend on a database, service, mailer, repository, or another component. A test double stands in for such a real collaborator so the test can control what it does or returns. Martin Fowler uses test double as the general term for these pretend objects, following the terminology of Gerard Meszaros’s xUnit Test Patterns. Fowler’s explanation of test doubles gives the category its name.
In Fowler’s narrower classification, a mock is programmed with expectations about how the unit should interact with it. The test then verifies those interactions—for example, that a notification service was called with the required message. Fowler calls this behavior verification. By contrast, state verification checks a result or state after the code runs, such as whether an output value is correct. Fowler’s article on mocks and stubs explains the distinction.
What is the difference between mocks and stubs?
A stub provides configured responses so the test can exercise the unit with predictable inputs. The test usually checks the resulting output or state, rather than whether the unit made a particular call to the stub. A mock carries interaction expectations, and the test checks whether those expectations were met.
| Test double | What it does | What the test typically checks |
|---|---|---|
| Dummy | Fills a parameter or other required slot but is not used by the test. | The double itself is not the subject of an assertion. |
| Fake | Provides a simplified working implementation, such as an in-memory substitute for a more complex collaborator. | State or output produced through that implementation. |
| Stub | Returns prepared answers to calls. | The unit’s resulting state or output. |
| Spy | Records information about calls made to it. | Recorded call information, when relevant to the test. |
| Mock | Has expectations about interactions with the unit. | Whether expected calls occurred, often including their arguments. |
These are roles, not necessarily separate classes in a testing library. One tool may offer an object that can return configured values, record calls, and check expectations. For a specific test, focus on what the double is doing and what the assertion proves.
When should you use a mock?
Use a mock when the interaction itself is part of the behavior you need to protect. For instance, an order-failure path may be required to send a notification, or a boundary may need to receive a particular argument. A mock can also help control a collaborator that would otherwise be awkward to use in a test.
- Choose an interaction expectation when the requirement is that a specific collaborator be called in a particular way.
- Choose a stub when the unit needs a predictable response but the call itself is not what the test is about.
- Choose a fake when a small, simplified implementation makes it practical to test resulting state or output.
- Prefer a state or output assertion when that directly demonstrates the behavior users or other components rely on.
Keep interaction assertions tied to requirements. Checking every internal call, argument, or exact call count can make a test depend on how the code is written rather than what it must do. Microsoft’s unit-testing guidance on mocking warns that this coupling can force test changes after implementation refactors, even when the meaningful behavior has not changed.
How mocking works in Python
Python’s unittest.mock library supports both controlled responses and interaction assertions. Its Python 3.10 documentation describes setting return values or side effects, checking which methods were used and with what arguments, and using patch() to replace a module or class attribute for a test scope. The patched attribute is restored afterward. A spec can restrict which attributes are available on a mock. See the Python 3.10 unittest.mock documentation for the documented API; syntax and details should be checked against the Python version a project uses.
Why the terminology can be confusing
“Mock” is not used identically across every source or ecosystem. Fowler follows the narrower classification above. Android’s guidance distinguishes mocks from stubs, fakes, dummies, and spies, while also warning that definitions can conflict. Microsoft describes common .NET usage and notes that it differs from the classic test-double vocabulary. Android’s guide to test doubles also notes that dependency injection can make dependencies easier to replace when tests cannot otherwise control how objects are created.
When reading framework documentation or code, check what its “mock” object actually does: whether it only returns configured values, records calls, enforces expectations, or combines those capabilities. Naming the role and the assertion in your test is more useful than assuming every tool follows one definition.
Quick Recap
Best Value
Rank #4
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
