unittest.mock模拟测试

Python进阶编程专题 · 用Mock隔离依赖进行可靠测试

专题：Python进阶编程系统学习

关键词：Python, unittest.mock, Mock, MagicMock, patch, side_effect, autospec, pytest-mock

一、概述：为什么需要Mock

在编写单元测试时，被测函数或方法往往依赖于外部资源——HTTP请求、数据库查询、文件系统读写、系统时间等。这些外部依赖带来几个棘手问题：测试执行速度慢（网络IO）、测试结果不稳定（外部服务宕机）、难以构造边界条件（网络超时、数据库断连）。Mock技术的核心思想正是用轻量的模拟对象替换真实依赖，让测试聚焦于被测代码自身的逻辑正确性。

Python标准库中的 unittest.mock 模块（自Python 3.3起成为内置模块）提供了完善的模拟测试工具。它的设计哲学是"记录-重放"：Mock对象记录所有对其属性和方法的访问，然后测试代码通过断言验证这些访问是否符合预期。本文将深入讲解 unittest.mock 的核心概念和进阶用法，帮助读者在项目中写出高质量、可维护的单元测试。

最佳实践提示：Mock测试应该遵循"模拟外部，保留内部"的原则——对网络IO、数据库、文件系统、时钟等外部依赖进行模拟，但对被测试模块自身的内部逻辑不要过度mock，否则测试将失去意义。

二、Mock与MagicMock对象创建

Mock 是 unittest.mock 模块的核心类。创建一个Mock对象非常简单：直接实例化即可。Mock对象的最大特点是"一切皆可访问"——你访问它的任何属性或方法都不会报错，而是返回另一个Mock对象。

# 最基本的Mock创建
from unittest.mock import Mock, MagicMock

# 创建一个Mock对象
mock_obj = Mock()
print(mock_obj)        # <Mock id='...'>

# 访问不存在的属性——不会报错，返回新的Mock
result = mock_obj.some_attribute
print(result)          # <Mock name='mock.some_attribute' id='...'>

# 调用不存在的方法——同样不报错
mock_obj.some_method(1, 2, key='value')

MagicMock 是 Mock 的子类，额外预定义了所有Python魔术方法（dunder methods，即双下划线方法）。当你需要模拟支持 __len__、__iter__、__getitem__、__enter__（上下文管理器）等行为的对象时，应当使用 MagicMock 而非 Mock。

# Mock 与 MagicMock 的对比
from unittest.mock import Mock, MagicMock

plain_mock = Mock()
try:
    len(plain_mock)       # TypeError: object of type 'Mock' has no len()
except TypeError as e:
    print(e)

magic_mock = MagicMock()
print(len(magic_mock)) # 默认返回 0

# MagicMock 支持迭代和索引
print(magic_mock[0])   # <MagicMock name='mock.__getitem__()'>
print(magic_mock + 1)  # <MagicMock name='mock.__add__()'>

经验法则：在大多数场景下直接使用 MagicMock 即可，因为它比 Mock 更"宽容"——不会因为底层代码调用了魔术方法而抛出 TypeError。仅当你需要严格限制接口、确保测试对象没有意外支持某些操作时，才使用 Mock。

2.1 Mock对象命名

为Mock对象指定 name 参数有助于调试。当断言失败时，名称会出现在错误信息中，帮助快速定位是哪个Mock出了问题。

from unittest.mock import MagicMock

user_service = MagicMock(name='user_service')
# 断言失败时，错误信息会包含 'user_service'
user_service.get_user(1)
print(user_service.method_not_called)  # name='user_service.method_not_called'

三、配置行为：return_value 与 side_effect

创建Mock对象后，需要告诉它"当被调用时应该返回什么"或"应该执行什么操作"。这是通过 return_value 和 side_effect 两个属性实现的——它们是Mock测试的"行为配置中心"。

3.1 return_value：固定返回值

当Mock被调用时，返回预先设定的值。这是最简单的行为配置方式。

from unittest.mock import MagicMock

# 方法1：构造函数传入
mock_db = MagicMock(return_value='连接成功')
print(mock_db())  # 连接成功

# 方法2：属性赋值
mock_api = MagicMock()
mock_api.return_value = {'status': 'ok', 'data': [1, 2, 3]}
print(mock_api())  # {'status': 'ok', 'data': [1, 2, 3]}

# 方法3：配置属性的返回值
mock_response = MagicMock()
mock_response.status_code = 200
mock_response.json.return_value = {'id': 42}
print(mock_response.status_code)  # 200
print(mock_response.json())        # {'id': 42}

3.2 side_effect：高级行为控制

side_effect 比 return_value 强大得多，它支持三种用法：抛出异常、返回迭代序列、以及通过可调用对象动态计算返回值。当 side_effect 被设置时，return_value 被忽略。

# 用法1：抛出异常——模拟错误场景
mock_network = MagicMock()
mock_network.side_effect = ConnectionError('网络超时')
try:
    mock_network()
except ConnectionError as e:
    print(e)  # 网络超时

# 用法2：可迭代对象——不同调用返回不同值
mock_queue = MagicMock()
mock_queue.side_effect = ['msg1', 'msg2', StopIteration()]
print(mock_queue())  # msg1
print(mock_queue())  # msg2
try:
    mock_queue()
except StopIteration:
    print('队列已空')

# 用法3：可调用对象——基于参数动态返回
def dynamic_response(url, **kwargs):
    if 'api' in url:
        return {'code': 0, 'result': 'success'}
    elif 'timeout' in str(kwargs):
        raise TimeoutError('请求超时')
    return {'code': -1, 'result': 'unknown'}

mock_request = MagicMock()
mock_request.side_effect = dynamic_response
print(mock_request('https://api.example.com'))
# {'code': 0, 'result': 'success'}

side_effect 与 return_value 的关系：二者是互斥的。当 side_effect 被设置为非 None 值时，return_value 被忽略。将 side_effect 设为 None 可恢复 return_value 的行为。对于迭代器类型的 side_effect，耗尽迭代器后Mock调用将返回 return_value（默认是另一个Mock）。

四、断言方法：验证调用行为

配置好Mock的行为之后，被测代码会调用这个Mock。接下来需要验证——调用是否发生了？传入了什么参数？调用了多少次？unittest.mock 提供了一组语义清晰的断言方法。

4.1 核心断言方法速查表

断言方法	用途	典型场景
`assert_called()`	至少被调用一次	确保关键逻辑被执行
`assert_called_once()`	恰好被调用一次	确保初始化逻辑只触发一次
`assert_called_with(a, *kw)`	最近一次调用使用了指定参数	验证参数传递正确
`assert_called_once_with(a, *kw)`	仅被调用一次且参数匹配	验证一次性操作（如发送邮件）
`assert_any_call(a, *kw)`	任意一次调用使用了指定参数（不关心次数）	验证某参数组合出现在多次调用中
`assert_not_called()`	从未被调用	验证短路逻辑、缓存命中
`assert_has_calls(calls, any_order)`	存在一组调用（支持任意顺序）	验证多步骤调用序列

from unittest.mock import MagicMock, call

mock = MagicMock()

# 执行若干调用
mock(1, x='a')
mock(2, y='b')
mock(1, x='a')  # 重复第一次调用

# 基本断言
mock.assert_called()                    # 通过
mock.assert_called_with(1, x='a')  # 检查最后一次调用

# assert_called_once 会失败——调用了3次
try:
    mock.assert_called_once()
except AssertionError as e:
    print("Expected: mock was called 3 times")

# 检查任意一次调用是否符合参数
mock.assert_any_call(2, y='b')  # 通过

# 检查调用序列（使用 call 辅助对象）
expected_calls = [call(1, x='a'), call(2, y='b')]
mock.assert_has_calls(expected_calls)    # 通过，按顺序匹配子序列

# 不关心顺序
mock.assert_has_calls(expected_calls, any_order=True)  # 通过

4.2 call_args 与 call_count 属性

除了断言方法，Mock对象还暴露了调用记录属性，可用于自定义验证逻辑或调试。

from unittest.mock import MagicMock

mock = MagicMock()
mock(10, 20, flag=True)
mock('hello')

print(mock.call_count)          # 2
print(mock.called)              # True
print(mock.call_args)           # call('hello') —— 最近一次调用的参数
print(mock.call_args_list)     # [call(10, 20, flag=True), call('hello')]
print(mock.call_args[0])       # ('hello',) —— 位置参数
print(mock.call_args[1])       # {} —— 关键字参数

调试技巧：在编写复杂测试时，可以先临时 print(mock.mock_calls) 查看完整的调用历史，了解被测代码实际调用了Mock的哪些方法和属性。这对于理解复杂的调用链非常有帮助。

五、patch 系列：拦截与替换依赖

手动创建Mock对象并注入到被测代码中是可行的，但不够优雅。patch 函数的职责是在测试期间临时替换目标对象的属性（或整个对象）为Mock，测试结束后自动恢复。这是 unittest.mock 中最常用的功能，也是实现"控制反转"测试的核心机制。

5.1 patch 的基本用法——装饰器与上下文管理器

patch 有两种等价的使用形式：作为装饰器（影响整个测试方法）和作为上下文管理器（影响测试方法中的部分代码块）。

from unittest.mock import patch
import requests  # 假设被测代码中使用了 requests.get()

# ── 场景：假设我们有这样一个函数 ──
def get_user_name(user_id):
    resp = requests.get(f'https://api.example.com/users/{user_id}')
    data = resp.json()
    return data['name']

# ── 测试：装饰器方式 ──
@patch('requests.get')
def test_get_user_name_decorator(mock_get):
    # 配置Mock
    mock_response = MagicMock()
    mock_response.json.return_value = {'name': 'Alice'}
    mock_get.return_value = mock_response

    # 执行被测函数
    name = get_user_name(1)

    # 验证结果
    assert name == 'Alice'

    # 验证Mock被正确调用
    mock_get.assert_called_once_with('https://api.example.com/users/1')

# ── 测试：上下文管理器方式 ──
def test_get_user_name_context():
    with patch('requests.get') as mock_get:
        mock_response = MagicMock()
        mock_response.json.return_value = {'name': 'Bob'}
        mock_get.return_value = mock_response

        name = get_user_name(2)

        assert name == 'Bob'
        mock_get.assert_called_once_with('https://api.example.com/users/2')

重要——patch 的路径规则：patch 的第一个参数是字符串形式的"点分路径"。这个路径指的是在被测代码中导入的位置，而不是定义的位置。例如，如果被测代码写的是 from mymodule import requests，那么 patch('mymodule.requests.get') 才是正确的路径。错误使用路径是Mock测试中最常见的调试难题。

5.2 patch.object：针对对象属性

当需要替换某个已存在对象的属性时，使用 patch.object 更加语义化。它接收一个对象和一个属性名字符串。

from unittest.mock import patch, MagicMock
import os

# 场景：替换 os.environ
@patch.object(os, 'environ', {'DATABASE_URL': 'sqlite:///test.db'})
def test_with_fake_env(mock_environ):
    from myapp import config
    assert config.DATABASE_URL == 'sqlite:///test.db'

# 或者使用上下文管理器
def test_path_join():
    with patch.object(os.path, 'sep', '\\'):
        assert os.path.join('a', 'b') == 'a\\b'

5.3 patch.multiple：批量替换

当需要同时替换同一个模块或对象的多个属性时，patch.multiple 可以避免嵌套多个 patch。

from unittest.mock import patch, MagicMock

# 同时替换一个模块中的多个函数
@patch.multiple('mymodule',
                 get_user=MagicMock(return_value={'id': 1}),
                 send_email=MagicMock(),
                 validate_token=MagicMock(return_value=True))
def test_batch_patch(get_user, send_email, validate_token):
    # 这三个参数已经全部被替换为Mock
    from mymodule import process_user
    process_user(1)
    get_user.assert_called_once_with(1)
    send_email.assert_called_once()

装饰器参数的名称必须与 patch.multiple 中指定的属性名一致。如果使用 create=True 参数，即使目标属性原本不存在也会创建Mock——这在替换动态属性时很实用。

5.4 patch.dict：临时修改字典

patch.dict 专门用于临时修改字典对象（如 os.environ、sys.modules），测试结束自动恢复原始内容。

from unittest.mock import patch
import os

# 添加/更新环境变量，测试结束自动恢复
@patch.dict('os.environ', {'DEBUG': 'true', 'API_KEY': 'test-key-123'})
def test_with_env_vars():
    assert os.environ['DEBUG'] == 'true'
    assert os.environ['API_KEY'] == 'test-key-123'

# 也可以清除某些key
@patch.dict('os.environ', {}, clear=True)  # 完全清空环境变量
def test_no_env():
    print(os.environ)  # {}

最佳实践：patch.dict('os.environ', ...) 是修改环境变量最安全的方式。切勿在测试中直接修改 os.environ，那样可能会污染其他测试用例或导致难以排查的副作用。

5.5 patch 的新式用法——as 参数与自动注入

在Python 3.8+中，@patch 支持通过 new_callable 指定Mock的工厂类，并且装饰器的参数顺序与堆叠顺序一致（即最外层的 @patch 对应第一个参数）。

from unittest.mock import patch, MagicMock

# 堆叠多个patch——参数顺序与装饰器顺序相反（从下往上）
@patch('module_a.func1')
@patch('module_b.func2')
@patch('module_c.func3', new_callable=MagicMock)
def test_stacked(mock_func3, mock_func2, mock_func1):
    # 注意：mock_func3 对应最下面的 @patch，是第一个参数
    print(mock_func3, mock_func2, mock_func1)

六、spec 参数：限制Mock接口

默认情况下Mock对象允许访问任何属性——这是一个双刃剑。好处是灵活，坏处是：如果你在测试中写了一个不存在的属性名（例如把 status_code 误拼为 status_codee），Mock不会报错，而是默默创建一个新的Mock，导致测试虽然"通过"但实际并未验证正确行为。

spec 参数正是用来解决这个问题的：将Mock限制为只能访问某个类或对象已有的属性，访问不存在的属性时抛出 AttributeError。

from unittest.mock import MagicMock
from collections import namedtuple

# 定义一个真实类
class HttpResponse:
    def __init__(self):
        self.status_code = 200
        self.headers = {}

    def json(self):
        return {'ok': True}

# 使用 spec 限制Mock只能访问 HttpResponse 的属性和方法
mock = MagicMock(spec=HttpResponse)
print(mock.status_code)   # <MagicMock> —— 合法属性
print(mock.json)          # <MagicMock> —— 合法方法

# 访问不存在的属性——抛出 AttributeError
try:
    mock.nonexistent_attr
except AttributeError as e:
    print("捕获到 AttributeError:", e)

# spec 也可用于已有实例
resp = HttpResponse()
instance_mock = MagicMock(spec=resp)
print(instance_mock.status_code)  # <MagicMock>

核心价值：spec 在重构时尤其有价值——当真实类的接口发生变化时，使用 spec 的测试会立即失败，提醒你更新测试代码。这比"测试默默通过但实际已经在测错误的东西"要好得多。spec 的本质是让Mock成为真实对象接口的"看门人"。

七、autospec：自动匹配原对象接口

spec 解决了"属性不存在"的问题，但它还有一个局限：不检查调用签名。即使一个方法需要两个参数，你可能只用了一个参数调用它Mock也不会报错。这会让测试放过严重的不兼容问题。

autospec（自动规格）在 spec 的基础上更进一步——它会检查调用时传入的参数是否与原函数的签名匹配，包括参数数量、默认值、keyword-only 参数等。

from unittest.mock import create_autospec

# 真实函数：需要2个必选参数
def send_notification(user_id, message, priority='normal'):
    pass

# 使用 create_autospec 创建自动规格Mock
mock_send = create_autospec(send_notification)

# 正确调用——通过
mock_send(1, 'hello')
mock_send(2, 'hi', priority='high')

# 错误调用——缺少必选参数，将抛出 TypeError
try:
    mock_send(1)  # missing 1 required argument: 'message'
except TypeError as e:
    print("签名校验失败:", e)

# ── 在 patch 中使用 autospec ──
from unittest.mock import patch

@patch('mymodule.send_notification', autospec=True)
def test_with_autospec(mock_send):
    # 调用时使用了错误的参数数量——会立即失败
    mock_send(1, 'msg')  # 正确
    # mock_send(1)  # 如果取消注释，会因缺少参数而抛出 TypeError

# autospec 还支持类方法、静态方法、属性等
class Calculator:
    @staticmethod
    def add(a, b):
        return a + b

    @classmethod
    def create_default(cls, initial_value=0):
        return cls()

# 为类创建 autospec
MockCalculator = create_autospec(Calculator)
# MockCalculator.add(1)          # TypeError: 缺少参数 b
# MockCalculator.add(1, 2, 3)    # TypeError: 过多参数
MockCalculator.add(1, 2)        # 通过

何时使用 autospec：在团队开发或大型项目中，强烈建议对 patch 启用 autospec=True。它虽然让测试代码稍微多写几行，但在重构和升级依赖库时可以避免大量"假通过"的测试。这是Mock测试中"越严格越安全"理念的最佳体现。

八、与 pytest 集成：mocker fixture

pytest 是Python社区最流行的测试框架。pytest-mock 插件是 unittest.mock 与 pytest 之间的桥梁，它提供了一个 mocker fixture，将 patch、patch.object 等功能封装成更简洁的API。

# 安装：pip install pytest-mock
# 文件：test_service.py

# ── 使用 mocker fixture —— 无需 import patch ──
def test_get_user(mocker):
    # mocker.patch 等价于 unittest.mock.patch
    mock_get = mocker.patch('requests.get')
    mock_get.return_value.json.return_value = {'name': 'Charlie'}

    from myapp.service import get_user
    user = get_user(1)

    assert user['name'] == 'Charlie'
    mock_get.assert_called_once_with('https://api.example.com/users/1')

# ── mocker.patch.object 的简洁用法 ──
def test_config(mocker):
    mocker.patch.object(os, 'environ', {'MODE': 'testing'})
    from myapp import config
    assert config.MODE == 'testing'

# ── mocker 自动清理——无需手动恢复 ──
# pytest-mock 会在每个测试结束后自动撤销所有 patch，
# 避免测试间的相互干扰。这是它优于手动 with patch() 的主要优势。

# ── spy 功能——部分模拟原始对象 ──
def test_spy(mocker):
    class Logger:
        def info(self, msg):
            return f"[INFO] {msg}"

    logger = Logger()
    spy = mocker.spy(logger, 'info')
    result = logger.info('test')

    assert result == '[INFO] test'   # 原始方法仍被调用
    spy.assert_called_once_with('test')  # 同时验证调用

mocker.spy 是一个独特的功能——它会包裹一个真实对象的方法，既执行原始逻辑（让测试获得真实结果），又记录所有调用信息（让测试可以断言调用行为）。这在需要"部分模拟"（只验证不替换）的场景中非常有用。

pytest-mocker 的核心优势：① 无需显式的 from unittest.mock import patch；② 自动清理mock，避免测试间干扰；③ 提供 spy 等增强功能；④ 与pytest的fixture机制完美融合。在项目中推荐使用 pytest + pytest-mock 的组合。

九、实战案例：隔离外部依赖

前面讲解了Mock的各项技术细节，现在通过三个完整的实战案例展示如何将它们组合起来解决真实世界的问题。

9.1 案例一：外部API调用测试

假设有一个天气查询服务，它调用外部天气API并处理结果。我们不想在测试时真的发出HTTP请求。

# 被测代码：weather_service.py
import requests

class WeatherService:
    BASE_URL = 'https://api.weather.com/v1'

    def get_temperature(self, city):
        url = f'{self.BASE_URL}/current/{city}'
        resp = requests.get(url, timeout=5)
        resp.raise_for_status()
        data = resp.json()
        return data['current']['temp_c']

# 测试代码：test_weather.py
import pytest
from weather_service import WeatherService

class TestWeatherService:
    def test_get_temperature_success(self, mocker):
        # 准备Mock响应
        mock_resp = MagicMock(spec=requests.Response)
        mock_resp.json.return_value = {
            'current': {'temp_c': 22.5, 'humidity': 60}
        }
        mock_get = mocker.patch('requests.get', return_value=mock_resp)

        # 执行
        service = WeatherService()
        result = service.get_temperature('beijing')

        # 验证
        assert result == 22.5
        mock_get.assert_called_once_with(
            'https://api.weather.com/v1/current/beijing',
            timeout=5
        )

    def test_get_temperature_network_error(self, mocker):
        # 模拟网络超时
        mocker.patch('requests.get', side_effect=ConnectionError('网络不可达'))

        service = WeatherService()
        with pytest.raises(ConnectionError):
            service.get_temperature('tokyo')

    def test_get_temperature_http_error(self, mocker):
        # 模拟HTTP 404错误
        mock_resp = MagicMock(spec=requests.Response)
        mock_resp.raise_for_status.side_effect = requests.HTTPError('404 Not Found')
        mocker.patch('requests.get', return_value=mock_resp)

        service = WeatherService()
        with pytest.raises(requests.HTTPError):
            service.get_temperature('unknown')

这个案例展示了三个关键点：spec=requests.Response 确保Mock不会意外引入不存在的属性；side_effect 用于模拟异常；每个测试用例覆盖一个独立的场景（成功、网络错误、HTTP错误）。

9.2 案例二：数据库操作隔离测试

数据库是另一个典型的需要隔离的依赖。通过Mock数据库连接和游标，我们可以验证SQL语句的构建和执行。

# 被测代码：user_repo.py
import sqlite3

class UserRepository:
    def __init__(self, db_path):
        self.conn = sqlite3.connect(db_path)

    def get_active_users(self):
        cursor = self.conn.cursor()
        cursor.execute('SELECT id, name, email FROM users WHERE active = 1')
        return cursor.fetchall()

    def create_user(self, name, email):
        cursor = self.conn.cursor()
        cursor.execute(
            'INSERT INTO users (name, email, active) VALUES (?, ?, 1)',
            (name, email)
        )
        self.conn.commit()
        return cursor.lastrowid

# 测试代码：test_user_repo.py
def test_get_active_users(mocker):
    # Mock 数据库连接和游标
    mock_cursor = MagicMock()
    mock_cursor.fetchall.return_value = [
        (1, 'Alice', 'alice@example.com'),
        (2, 'Bob', 'bob@example.com'),
    ]
    mock_conn = MagicMock()
    mock_conn.cursor.return_value = mock_cursor

    # 注入Mock——patch 类的构造函数
    mocker.patch('sqlite3.connect', return_value=mock_conn)

    # 执行测试
    repo = UserRepository(':memory:')
    users = repo.get_active_users()

    # 验证结果
    assert len(users) == 2
    assert users[0][1] == 'Alice'

    # 验证SQL执行
    mock_cursor.execute.assert_called_once_with(
        'SELECT id, name, email FROM users WHERE active = 1'
    )

def test_create_user(mocker):
    mock_cursor = MagicMock()
    mock_cursor.lastrowid = 100
    mock_conn = MagicMock()
    mock_conn.cursor.return_value = mock_cursor
    mocker.patch('sqlite3.connect', return_value=mock_conn)

    repo = UserRepository(':memory:')
    user_id = repo.create_user('Charlie', 'charlie@example.com')

    assert user_id == 100
    mock_cursor.execute.assert_called_once_with(
        'INSERT INTO users (name, email, active) VALUES (?, ?, 1)',
        ('Charlie', 'charlie@example.com')
    )
    mock_conn.commit.assert_called_once()

这个案例的关键模式是"链式Mock"：Mock连接 → Mock返回的游标 → Mock游标的 execute 和 fetchall。这种模式适用于任何需要进行链式调用的测试场景。

9.3 案例三：时间依赖测试

代码中涉及系统时间的逻辑是最难测试的之一。使用Mock可以"冻结"时间，让测试不再受实际时间影响。

# 被测代码：order_service.py
import datetime

def is_order_expired(order_time, expiration_hours=24):
    if order_time is None:
        return False
    now = datetime.datetime.now()
    delta = now - order_time
    return delta.total_seconds() > expiration_hours * 3600

# 测试代码：test_order.py
import datetime
from unittest.mock import MagicMock

def test_order_not_expired(mocker):
    # "冻结"当前时间
    frozen_time = datetime.datetime(2026, 5, 5, 12, 0, 0)
    mocker.patch('datetime.datetime', now=lambda: frozen_time)

    # 订单在1小时前创建，未过期
    order_time = frozen_time - datetime.timedelta(hours=1)

    from order_service import is_order_expired
    assert is_order_expired(order_time) == False

def test_order_expired(mocker):
    frozen_time = datetime.datetime(2026, 5, 5, 12, 0, 0)
    mocker.patch('datetime.datetime', now=lambda: frozen_time)

    # 订单在48小时前创建，已过期
    order_time = frozen_time - datetime.timedelta(hours=48)

    from order_service import is_order_expired
    assert is_order_expired(order_time) == True

def test_order_none_time(mocker):
    # 边界条件：订单时间为 None
    from order_service import is_order_expired
    assert is_order_expired(None) == False

时间测试的注意事项：Mock datetime.datetime 时要特别小心，因为 datetime.datetime 本身是一个C扩展类型，直接 mocker.patch 可能在某些Python版本上有兼容性问题。替代方案是使用 freezegun 库（pip install freezegun），它提供了更优雅的时间冻结API。

十、进阶模式与最佳实践

经过前面的学习，你已经掌握了 unittest.mock 的主要API。下面补充一些进阶模式和最佳实践，帮助你在真实项目中写出更健壮的测试。

10.1 NEVER Mock 你不拥有的代码

核心原则：只Mock那些你的代码直接调用的边界接口。不要Mock标准库内部实现细节或第三方库的内部函数——那样会让测试与实现过度耦合，重构时测试比代码先坏掉。

10.2 使用 contextlib 管理复杂的Mock生命周期

from contextlib import ExitStack
from unittest.mock import patch

def test_complex_scenario():
    # 使用 ExitStack 动态管理多个patch
    with ExitStack() as stack:
        mock_get = stack.enter_context(patch('requests.get'))
        mock_post = stack.enter_context(patch('requests.post'))
        mock_logger = stack.enter_context(patch('app.logger.info'))

        mock_get.return_value.status_code = 200
        mock_post.return_value.json.return_value = {'ok': True}

        # 执行测试逻辑...
        pass
    # 退出 with 块后所有patch自动恢复

10.3 用 wrapper 模式保护不可mock的模块

部分C扩展模块无法直接patch。这时可以创建一个薄包装层（wrapper），将外部依赖封装在自己的类中，然后Mock这个包装类。

# 笨拙方式——直接 mock Redis（可能失败）
# mocker.patch('redis.Redis.get')

# 推荐方式——先包装再mock
class CacheClient:
    def __init__(self, redis_client):
        self._redis = redis_client

    def get(self, key):
        return self._redis.get(key)

    def set(self, key, value, ttl=300):
        return self._redis.setex(key, ttl, value)

# 测试时Mock CacheClient 即可
mock_cache = MagicMock(spec=CacheClient)
mock_cache.get.return_value = 'cached_value'

10.4 关注行为而非实现

好的Mock测试：验证"函数返回了什么"和"调用了哪些外部接口（以什么参数）"。
坏的Mock测试：验证"函数内部第几步做了什么事"——这会把测试变成实现细节的快照，每次重构都会破坏测试。

10.5 善用 PropertyMock

from unittest.mock import PropertyMock, patch

class TemperatureSensor:
    @property
    def current_temperature(self):
        # 实际读取硬件，不可测试
        pass

# 使用 PropertyMock 模拟属性
def test_sensor():
    sensor = TemperatureSensor()
    with patch.object(
        TemperatureSensor,
        'current_temperature',
        new_callable=PropertyMock
    ) as mock_temp:
        mock_temp.return_value = 25.5

        assert sensor.current_temperature == 25.5

十一、常见陷阱与调试技巧

11.1 patch 路径错误

最常见的Mock错误。记住：patch的路径是"被测代码中导入的位置"，不是"定义的位置"。使用 print() 调试或设置 autospec=True 可以帮助快速发现路径问题。

11.2 忘记配置返回值

如果不设置 return_value，Mock被调用后返回另一个Mock对象。这在大多数情况下会导致后续的 .json() 等调用返回Mock而非期望数据，测试失败的原因可能难以定位。

11.3 Mock 之间互相干扰

在 pytest 的 mocker fixture 中，每个测试自动隔离。但在 unittest.TestCase 中，setUp 中创建的Mock可能会在测试间共享，导致调用记录互相污染。解决方案：在 setUp 中创建Mock，然后在 tearDown 中重置，或使用 setUp 中调用 mock.reset_mock()。

# 重置Mock的调用记录
mock = MagicMock()
mock(1)
mock(2)
print(mock.call_count)    # 2

mock.reset_mock()
print(mock.call_count)    # 0 —— 调用记录已清空
# 注意：reset_mock 也会清空 return_value、side_effect 等配置

11.4 使用 wraps 保留部分行为

# 创建一个包装真实对象的Mock——部分真实，部分模拟
class RealService:
    def get_data(self):
        return 'real_data'

    def side_effect(self):
        return 'expensive_operation'

# 使用 wraps——调用真实方法但可跟踪调用记录
real = RealService()
mock = MagicMock(wraps=real)

print(mock.get_data())    # 'real_data' —— 实际调用了真实方法
mock.get_data.assert_called_once()  # 同时可断言

# 也可以覆盖某个方法
mock.side_effect = MagicMock(return_value='mocked')
print(mock.side_effect())  # 'mocked'

十二、核心要点总结

Mock的本质：用轻量模拟对象替换真实依赖，记录所有调用行为供后续断言验证。"记录-重放"是核心设计模式。
Mock vs MagicMock：MagicMock 预定义了所有魔术方法（__len__、__iter__ 等），能应对更广泛的场景。优先使用 MagicMock。
return_value vs side_effect：固定返回值用 return_value；异常/序列/动态逻辑用 side_effect。二者互斥。
patch 路径规则：路径是"被测代码导入的位置"，而非"定义的位置"。可使用 where 参数辅助定位。
spec 与 autospec：spec 限制属性访问；autospec 进一步验证调用签名。团队项目中建议对公共API默认启用 autospec。
pytest-mock 集成：mocker fixture 提供更简洁的API和自动清理能力。mocker.spy 实现"部分模拟"——保留原始行为的同时记录调用。
实战三剑客：外部API调用测试（Mock requests）、数据库隔离测试（Mock 连接+游标）、时间依赖测试（Mock datetime.now）。掌握这三个模式可覆盖大部分Mock需求。
最佳实践：Mock边界不Mock内部；行为验证替代实现验证；包装不可Mock的模块后再测试；善用 PropertyMock 模拟属性；借助 wraps 保留部分真实行为。
常见陷阱：路径错误、忘记配置返回值、Mock间相互污染、过度Mock导致测试脆弱。遇到问题优先检查 patch 路径和 return_value 配置。

十三、进一步思考

Mock测试是"测试金字塔"中单元测试层的重要工具，但它不是万能的。在实际项目中，应当构建多层次测试策略：用Mock测试实现快速、可靠的单元测试；用集成测试验证模块间的真实交互；用端到端测试覆盖关键业务路径。Mock的价值在于隔离——让每个测试只关注一个逻辑单元，从而在代码出问题时快速定位到故障点。

深入学习Mock还应该阅读官方文档中关于 unittest.mock 的高级特性：FILTER_DIR、mock_open、seal 函数（锁定Mock使其不能再创建新属性）等。掌握这些工具后，你会发现——不再有"不可测试"的代码，只有"设计不合理"的代码。良好的可测试性本身就是良好软件设计的标志。

推荐阅读：Python官方文档 unittest.mock 部分、Harry Percival 的 "Test-Driven Development with Python"、以及 pytest-mock 的文档。动手实践是最好的学习方式——试着为你手中的项目添加Mock测试，你会在实践中加深对这些概念的理解。