What is the purpose of unittest.mock, and when would you mock a dependency versus use a real implementation?
mock replaces collaborators to isolate the unit; use real implementations when the interaction is what you test
unittest.mock provides MagicMock and patch to replace objects during a test. The purpose is isolation: when you test a unit, you want failures to point at that unit's logic, not at a slow or unavailable collaborator. A mock also lets you assert interactions, such as that a payment provider was called exactly once with the right amount. The heuristic for choosing between mock and real is simple: mock when the collaborator is slow, non-deterministic, has side effects outside the test, or is not the thing under test. Use the real implementation when the interaction itself is the contract you are verifying, such as the SQL your repository generates or the exact bytes your serializer emits. Over-mocking is the most common failure mode: tests that assert on mock call shapes pass even when the real collaborator would reject the call.
- 1
Mock external services, clocks, randomness, filesystem paths outside tmp, and anything with side effects you do not want to trigger.
- 2
Prefer fakes (in-memory implementations of your own interface) over MagicMock for behavior-rich collaborators. Fakes catch interface drift, mocks do not.
- 3
Assert behavior sparingly. Asserting every call makes refactors painful and tests brittle.
- 4
Use autospec=True when mocking, so the mock enforces the real signature and catches wrong-argument errors.
- 5
Trade-off: mocks make tests fast and deterministic but reduce confidence in integration behavior. Pair them with a smaller set of integration tests.
- 6
Common mistake: patching the wrong symbol. Patch where the object is looked up, not where it is defined.
- 7
Common mistake: mocking the thing under test, which makes the test tautological.
- 8
Version note: unittest.mock has been in the stdlib since 3.3. autospec, spec_set, and AsyncMock (3.8+) are the modern features to use.
Scenario Questions
0-2 years experience
- 1You need to test a function that sends an email. How do you avoid sending a real email?
- 2Where do you apply patch: on the definition module or the usage module?
2-5 years experience
- 1A test passes against a mock but fails against the real HTTP API. What is the likely cause and how do you prevent it?
- 2You mock a repository and never verify the SQL it produces. What would have caught the schema bug?
5-8 years experience
- 1You refactor a module and many mocks break even though behavior is unchanged. How do you reduce this brittleness?
- 2You need to test a payment flow with retries and idempotency keys. What do you mock and what do you fake?
8+ years experience
- 1Design a test harness where external dependencies can be either faked in-process or run as local containers, switchable per test tier.
- 2Explain how to enforce interface contracts between your code and external providers using consumer-driven contract tests alongside mocks.
Follow-up Questions
- Why is patching the wrong symbol one of the most common mock bugs?
- When would an in-memory fake be a better choice than a MagicMock?