Mocking and Fixtures0%
Test-Driven Development

Mocking and Fixtures

Beginner12 min read•Updated: Jul 11, 2026
Study Materials

Mocking and Fixtures with unittest.mock

When testing complex software systems, isolating the unit under test from slow, non-deterministic, or hazardous external dependencies—such as third-party payment gateways, remote REST APIs, email servers, or physical disks—is a fundamental testing requirement.

In Python, the unittest.mock module provides a powerful mocking framework. Mastering Mock, MagicMock, and the @patch decorator allows you to simulate external behaviors, verify method call contracts, and avoid flaky tests.

1. Mock vs MagicMock

Both Mock and MagicMock dynamically generate attributes and methods upon access. Any accessed attribute returns a new Mock instance, recording how it was invoked:

Output
The Mock Object Contract
│
┌──────────────────────────────┴──────────────────────────────┐
▼ ▼
Standard Mock MagicMock
- Generic method calls - Inherits from Mock
- Records call_count, args, kwargs - Pre-populates all Python
Dunder Methods:
__iter__, __len__,
__enter__, __exit__,
__getitem__, __str__
Python
from unittest.mock import MagicMock, Mock
 
# 1. Standard Mock for generic function calls
service_mock = Mock()
service_mock.process_payment.return_value = {"status": "SUCCESS", "tx_id": "tx_9921"}
 
# Execute mock
response = service_mock.process_payment(amount=150.0, currency="USD")
print("Mock Response:", response)
 
# Verify invocation assertions
service_mock.process_payment.assert_called_once_with(amount=150.0, currency="USD")
print(f"Recorded calls count: {service_mock.process_payment.call_count}")
 
# 2. MagicMock for context managers and protocols
context_mock = MagicMock()
with context_mock as ctx:
print("Inside MagicMock context manager block!")
 
# MagicMock automatically implements and records __enter__ and __exit__
context_mock.__enter__.assert_called_once()
context_mock.__exit__.assert_called_once()

2. Dynamic Returns & Errors via side_effect

While return_value returns a static value, side_effect allows dynamic behavior:

  1. 1
    Raising Exceptions: Simulates network timeouts or HTTP 500 crashes.
  2. 2
    Sequential Returns: Returns different values on successive calls by providing an iterable.
  3. 3
    Dynamic Callables: Routes calls through a custom calculation function.
Python
from unittest.mock import Mock
 
# Scenario A: Simulating network failure
network_mock = Mock(side_effect=ConnectionResetError("Socket aborted by remote server"))
try:
network_mock()
except ConnectionResetError as err:
print(f"[RECOVERY] Caught simulated error: {err}")
 
# Scenario B: Sequential mock returns
counter_mock = Mock(side_effect=[10, 20, 30])
print(counter_mock()) # 10
print(counter_mock()) # 20
print(counter_mock()) # 30

3. The Golden Rule of Patching: Where to Patch

The @patch decorator replaces a target object with a Mock during test execution and automatically restores the original object upon completion.

The Golden Rule of Patching: Patch where an object is LOOKED UP, not where it is DEFINED.
Output
If file 'service.py' does:
from payment_lib import ChargeCard
──► WRONG: @patch("payment_lib.ChargeCard")
(service.py already imported its own local reference to ChargeCard!)
──► CORRECT: @patch("service.ChargeCard")
(Patches the reference where service.py looks it up!)

Visual Architecture & Process Flow

How data and code flow step-by-step

Flowchart
Step 1
def send_welcome
self, email: str
Step 2
bool:

4. Combining Pytest Fixtures with Mocks

In modern testing architectures, combine Pytest fixtures with unittest.mock.patch to create clean, modular mocked dependencies:

Python
import pytest
from unittest.mock import MagicMock, patch
 
class OrderService:
def __init__(self, payment_gateway):
self.gateway = payment_gateway
 
def place_order(self, amount: float) -> str:
res = self.gateway.charge(amount)
if not res.get("success"):
raise RuntimeError("Payment rejected")
return res["transaction_id"]
 
@pytest.fixture
def mock_gateway() -> MagicMock:
"""Fixture providing a pre-configured payment gateway mock."""
gateway = MagicMock()
gateway.charge.return_value = {"success": True, "transaction_id": "TXN_7749"}
return gateway
 
def test_order_placement_success(mock_gateway: MagicMock):
service = OrderService(payment_gateway=mock_gateway)
txn_id = service.place_order(99.99)
assert txn_id == "TXN_7749"
mock_gateway.charge.assert_called_once_with(99.99)

5. Architectural Summary Table

ToolPrimary PurposeKey Attribute / Method
MockLightweight object proxyreturn_value, side_effect, call_count
MagicMockSubclass implementing dundersSupports with, len(), iter(), str()
@patch(target)Replaces object during testTarget must be where name is looked up
patch.object(cls, 'attr')Replaces specific attribute on classSafer than string path when object is in scope
assert_called_with(*args)Verifies call parametersFails if arguments mismatch

Multiple Choice Questions

1.

What is the primary operational difference between Mock and MagicMock in Python's unittest.mock library? A. MagicMock runs twice as fast as Mock. B. MagicMock comes pre-configured with default implementations for all standard Python magic/dunder methods (such as __enter__, __exit__, __len__, __iter__), whereas Mock does not. C. Mock is deprecated in Python 3. D. MagicMock automatically commits database transactions.

Answer: B
Explanation:MagicMock is a subclass of Mock that implements Python's special dunder methods, allowing it to mimic containers, context managers, and iterables without manual setup.

2.

What is the "Golden Rule of Patching" when using unittest.mock.patch? A. Patch where the object is defined. B. Patch where the object is looked up / used, not where it was originally defined. C. Always patch built-in functions first. D. Only patch classes in the standard library.

Answer: B
Explanation:If module A imports from B import C, patching B.C has no effect on module A because A already holds its own reference. You must patch A.C.

3.

How can you configure a Mock object to raise a TimeoutError when called? A. my_mock.raise = TimeoutError B. my_mock.side_effect = TimeoutError("Connection timed out") C. my_mock.return_value = TimeoutError D. my_mock.error = True

Answer: B
Explanation:Setting side_effect to an exception class or instance instructs the mock to raise that exception whenever it is called.

4.

What does my_mock.assert_called_once_with("admin", port=8080) verify? A. That the mock was called at least 5 times. B. That the mock was called exactly once in total, and that its arguments during that single invocation strictly matched ("admin", port=8080). C. That the function returned True. D. That the network socket opened successfully.

Answer: B
Explanation:assert_called_once_with asserts both that the total invocation count equals 1 and that the arguments passed match the expected positional and keyword values.

5.

What happens to a patched object after a test decorated with @patch('module.Class') completes execution? A. The object remains permanently replaced by the mock. B. The patch automatically exits and restores the original un-mocked class reference in the target namespace. C. Python restarts the process. D. The module is deleted.

Answer: B
Explanation:patch acts as a context manager or function wrapper that guarantees the target namespace is cleanly un-patched and restored to its original state once the test exits.
Next Lesson

Test-Driven Development

Continue learning with hands-on practice, examples, and exercises in the upcoming topic.

Related Lessons

Previous LessonNext Lesson
Pytest for Advanced TestingTest-Driven Development

Practice Quiz

Test your understanding of this lesson with 5 questions. Each question has one correct answer.

PreviousNext
PrevNext