Pytest Mock实战精讲：搞定接口自动化与复杂依赖场景

做测试开发这几年，我用 Pytest 的时间占了一大半，而 Mock 又是这里面最容易被轻视、实际坑最多的东西。很多人对 Mock 的印象就停留在“把接口返回结果改成一个假数据”，直到某天被测函数调了三次外部服务、前两次抛异常第三次才成功，或者要 mock 的其实是个异步上下文管理器，才发现手里的那几招完全不够用。

这篇文章我不想讲那种“Mock 入门第一课”，而是把我在真实项目里反复用到的技巧、踩过的坑、以及为什么这样写才可靠的思路，一次性整理清楚。适合已经在用 Pytest 写接口自动化或单元测试，但遇到复杂依赖场景时不知道怎么下手的同学；也适合刚学完 Mock 基础语法，想知道“我到底该怎么组织代码”的新手。

1. 整体思路拆解：为什么你的测试离不开 Mock

1.1 先搞清楚 Mock 到底解决了什么问题

很多人对 Mock 的第一反应是“造假数据”，这个理解不能说错，但太窄了。Mock 真正解决的是测试里的不可控依赖问题。你写接口自动化，上游对接的是支付网关、短信通道、第三方开放平台，这些服务在你本地测试环境根本调不通；你写单元测试，被测函数要查数据库、读 Redis、请求另一个微服务，这些依赖一旦在 CI 环境里不稳定，测试就跟着挂了。

所以说，Mock 的价值在于把测试边界划清楚：你只测当前这段代码的逻辑是否正确，至于它依赖的外部服务长什么样，那是对方的事，不在你这次测试范围内。我用个直白的例子：你要测一个下单接口里“余额不足时返回错误码”的逻辑，如果每次都真的去扣一次钱，那测试就变成了破坏性测试；哪怕你用的是沙箱环境，也会有网络超时、并发冲突这些额外变量。把支付调用 mock 掉，让它在代码里返回“余额不足”，你才能稳定地验证自己的分支逻辑。

这背后的设计原则是：能用真实依赖就用真实依赖，只在慢、贵、不稳定时才 mock。测试金字塔里，单元测试层几乎可以全部 mock，集成测试层尽量用真实的轻量替代（比如 SQLite 代替 MySQL），端到端测试才尽量走真实链路。现在很多团队做接口自动化，一上来就把接口返回全部 mock 掉，结果线上出了问题测试照样绿，因为测试跑的是自己编的故事，不是真实数据。这种“过度 mock”其实是一种失效的自动化，你得当心。

1.2 Mock、Fake、Stub 的概念区分

Mock 这个词在使用中其实有点泛化，严格说起来，测试替身分好几种，搞清楚它们的区别能帮你选对方案：

• Stub（桩）：只返回预设数据，不记录调用过程。比如一个登录接口的桩，你让它返回 token，它就只有这一个功能。
• Fake（假实现）：一个轻量级的真实实现。比如内存版数据库、假邮件发送器。能用 Fake 解决的问题，不用 Mock。
• Mock（模拟对象）：不只返回数据，还能验证方法是否被调用、调用参数是什么、调用了几次。这才是 Mock 的核心能力。

我见过不少测试代码，把 Mock 当 Stub 用，只配置返回值，完全不做断言，测试结果自然是“永远绿”。Mock 名字本身就包含“验证交互”的意思，你用了 mock 却不去 assert_called_once_with，等于白用。

2. 核心细节解析与实操要点：从 Mock 对象到 patch 的完整掌握

2.1 Mock() 还是 MagicMock()，这是个问题

刚开始学 Mock，最容易被问住的一个问题就是：Mock 和 MagicMock 有什么区别？简单说，MagicMock 是 Mock 的子类，它额外实现了对 Python 魔术方法的 mock 支持。

什么叫魔术方法？就是那些以双下划线开头和结尾的方法，比如__eq__（判断相等）、__len__、__iter__、__getitem__这些。如果你的被测代码里会对 mock 对象做相等比较、取长度、遍历，那用普通 Mock 会直接报错，因为 Mock 没有实现这些特殊行为。

我举一个实际场景：被测函数对返回的数据做len(data) > 0判断，如果你用Mock()去模拟这个数据对象，len()会抛TypeError: object of type 'Mock' has no len()。但用MagicMock()，它默认就会返回 0，逻辑能顺利走下去。所以我的建议是：拿不准就用 MagicMock，除了极少数不需要魔术方法的场景，MagicMock 基本是万能选择。

注意，MagicMock 对魔术方法也有自己的“默认行为”：__len__返回 0，__bool__返回 True，__iter__返回空迭代器。这些默认值有时候会掩盖你代码里真实的 bug，比如本来应该非空的数据，因为 mock 默认长度是 0，断言直接通过，结果没测出数据为空时的错误分支。真项目里，我给 mock 配返回值时都会写清楚return_value，尽量不让默认值参与断言。

2.2 return_value 和 side_effect：一个管结果，一个管行为

配置 mock 的返回值，最基础的做法是：

mock_obj = MagicMock() mock_obj.get_user.return_value = {"id": 1, "name": "demo"}

但项目复杂之后，你会发现 return_value 有点太“死”了。比如模拟一个接口“第一次调用抛异常，第二次调用成功”，return_value 就做不到。这时候要上 side_effect。

side_effect有三种常见形态：

第一种，抛异常。你直接传一个异常实例，调用 mock 时就会抛出来：

mock_obj.call_api.side_effect = TimeoutError("connection timeout")

第二种，传一个可迭代对象。每次调用依次取一个值，适合模拟“第一次失败、第二次成功”这样的重试场景：

mock_obj.call_api.side_effect = [TimeoutError("timeout"), {"code": 0, "data": "ok"}]

第三种，传一个函数。函数接收调用参数并返回结果，这是最灵活的方式，适合根据入参动态生成返回：

def fake_response(url, **kwargs): if "user" in url: return {"id": 1, "name": "demo"} return {"code": 404} mock_obj.request.side_effect = fake_response

我要提醒一个细节：side_effect和return_value同时存在时，side_effect优先。如果side_effect是函数或列表，return_value根本不会起作用；如果side_effect是异常，那不管怎么调用，异常都会立刻抛出。实际写测试的时候，这两个别混着配，容易让后来的人看不懂你的意图。

2.3 patch 的三种用法：装饰器、上下文管理器、手动启停

patch是 pytest / unittest 里最核心的 mock 工具，它本质上是把某个模块下的名字临时替换成 mock 对象，测试结束后再恢复。

最常见的是用装饰器：

from unittest.mock import patch @patch("module_a.service.BillingAPI.charge") def test_order_insufficient_balance(mock_charge): mock_charge.return_value = {"code": 1001, "msg": "balance not enough"} # 被测代码

注意，装饰器参数是“导入路径的字符串”，不是已经 import 进来的对象。这个细节我单独展开讲：mock 的是“目标模块里被使用时的名字”，而不是定义处。比如from other_module import BillingAPI之后，BillingAPI 这个名字已经绑定到了当前模块的命名空间，你要 mock 的是当前模块.BillingAPI，而不是other_module.BillingAPI。这是个经典坑，我后面常见问题里会再说。

有的场景装饰器不够用，比如你只想在测试中段的时候临时替换，后面又恢复。这时候用上下文管理器：

def test_ctx(): with patch("module_a.service.BillingAPI.charge") as mock_charge: mock_charge.return_value = {"code": 1001} # do something

第三种是手动启停，适合在 setup 阶段统一 mock，teardown 阶段统一恢复：

def setup_method(self): self.mock_charge = patch("module_a.service.BillingAPI.charge").start() self.mock_charge.return_value = {"code": 0} def teardown_method(self): patch.stopall()

我个人在项目里用得最多的是上下文管理器，因为它作用域清晰，不会因为装饰器顺序影响可读性。用法上有个小技巧：装饰器和上下文管理器混用时，装饰器参数离函数最近的是第一个参数，它有严格的从下到上、从右到左的顺序，层数多的时候非常容易混淆。如果你发现自己已经叠了三层@patch，我建议直接拆成with patch嵌套，或者用fixture来处理，可读性会好很多。

2.4 patch.object 和 patch.dict：更精细地替换属性与字典

patch默认是替换一个名字，如果对象是个实例属性或者字典值，就需要更精确的工具。

patch.object用于替换某个对象的属性：

class Config: timeout = 5 @patch.object(Config, "timeout", 10) def test_timeout_config(): assert Config.timeout == 10

我的经验是，patch.object在测试依赖全局配置的代码时特别好用。比如服务端口、重试次数、开关状态，都可以通过这种方式临时改掉，测试结束自动恢复。

patch.dict用于替换字典里的值，最适合操作环境变量：

import os from unittest.mock import patch @patch.dict(os.environ, {"ENV": "dev", "API_KEY": "test-key"}) def test_env(): assert os.environ["ENV"] == "dev"

在接口自动化里，我用这个技巧做过不少事：模拟生产环境配置、切换不同的数据库连接串、伪造密钥等。patch.dict还有个参数clear=False，如果设置成 True，会先把原字典清空再注入新值，通常不建议用，容易误伤其他环境变量。

2.5 spec 参数与 autospec：别让 mock 悄悄接受不存在的属性

Mock 有一个让新手困惑的特性：它几乎接受任何属性和方法的访问，不存在的方法也会返回一个子 mock。比如：

mock_obj = Mock() mock_obj.nonexistent_method() # 不会报错，返回 Mock 对象

这在测试里是个隐患。假设被测代码误调用了一个不存在的方法，如果是真实对象，早就抛AttributeError了；但 mock 会默默返回一个假对象，测试继续往下走，直到后续逻辑出现更离奇的错误，排查的时候非常痛苦。

解决办法是给 mock 加spec参数，让 mock 只允许访问真实对象本来就有的属性：

class UserService: def get_user(self, uid): ... def delete_user(self, uid): ... mock_service = Mock(spec=UserService) mock_service.get_user(1) # 正常 mock_service.update_user(1) # 抛 AttributeError

patch也支持autospec=True：

@patch("module_a.service.UserService", autospec=True) def test_user(mock_service): mock_service.return_value.get_user.return_value = {"id": 1}

这里autospec=True会自动根据真实对象创建 spec，避免你 mock 出一个“不存在的接口”。说句实在话，spec这种能力在多人协作的项目里价值很大，它能尽早暴露调用方代码里的拼写错误和接口漂移问题，我强烈建议在测试公共模块时都加上。

3. 实操过程与核心环节实现：从简单 mock 到复杂场景的全流程推进

3.1 用 fixture 做 mock：pytest-mock 的 mocker 到底好在哪

pytest 本身没有内置 mock 的 fixture，要用unittest.mock直接写，代码倒也过得去。但当你需要同一份 mock 配置在多个测试里复用时，单纯靠 patch 装饰器就会让函数签名越来越臃肿。这个痛点正是pytest-mock插件要解决的。

pytest-mock提供了一个名叫mocker的 fixture，用法如下：

def test_order(mocker): mock_charge = mocker.patch("module_a.service.BillingAPI.charge") mock_charge.return_value = {"code": 1001, "msg": "balance not enough"} result = order_api.create(amount=100) assert result["code"] == 1001

mocker.patch和直接unittest.mock.patch的区别主要是：由 mocker fixture 管理的 patch，测试结束时会自动全部恢复，不需要手动写patch.stopall()。这一点在测试文件里一堆@patch装饰器时特别省心，不用担心某个 mock 泄漏到下一个测试里。

更关键的是，mocker 还能结合 fixture 做“注入式”的 mock。比如你有一个需要依赖第三方接口的服务类，可以在 fixture 里把它的依赖 mock 好，再返回给测试函数：

@pytest.fixture def order_service(mocker): svc = OrderService() mocker.patch.object(svc, "_call_payment", return_value={"code": 0, "payment_id": "p123"}) return svc def test_order_created(order_service): result = order_service.create(amount=99) assert result["payment_id"] == "p123"

这个模式在我看来，是 pytest 生态里最容易“上瘾”的写法：fixture 负责环境准备，mock 负责依赖隔离，测试函数只关心断言。代码结构清晰，后期维护成本极低。

3.2 异步接口的 Mock：AsyncMock 与各自的用法

现在的服务端开发，async/await 几乎是标配。用传统的 MagicMock 去 mock 异步函数会踩坑：调用一个 async 函数，返回的不是 coroutine 而是一个普通 MagicMock，然后被测试的代码里await mock_result直接报TypeError: object MagicMock can't be used in 'await' expression。

解法是用unittest.mock.AsyncMock，它能正确模拟异步函数的行为：

from unittest.mock import AsyncMock async def fetch_data(): pass # 真实实现 def test_async(mocker): mocker.patch("module_a.fetch_data", AsyncMock(return_value={"code": 0, "data": "ok"})) # 然后在异步测试里 await 调用

跑异步测试要装pytest-asyncio，测试函数加上@pytest.mark.asyncio或用asyncio.run()包一层。我的经验是：在一个中大型项目里，异步 mock 的场景往往和async with上下文管理器绑在一起。比如要 mock 一个异步的数据库连接：

mock_conn = AsyncMock() mock_conn.__aenter__.return_value = mock_conn mock_conn.execute.return_value = [{"id": 1}] with patch("module_a.db.get_connection", return_value=mock_conn): result = await some_service.query()

这段代码的关键在于，__aenter__也要返回一个 AsyncMock，这样async with才能正常进入。如果你发现 mock 的 async 管理器进不去，多半是忘了配__aenter__。实际操作中，我用嵌套 AsyncMock 时会把这两行写在一起，一眼就能看出意图。

3.3 接口自动化里的 Mock 实战：不依赖真实环境的联调利器

很多做接口自动化的同学，测试用例里最头疼的就是第三方接口：实时汇率、天气、短信验证码、微信支付回调。这些接口要么本地连不上，要么有调用次数限制，要么数据不可控。Mock 在这块的使用方式，不是简单地把返回写死，而是可以组织成一套“可切换”的策略。

我的工程实践是：环境变量控制 mock 开关，测试代码统一走一个 mock 工厂。以一个请求第三方天气接口的例子说明：

import os import requests from unittest.mock import patch def get_weather(city): resp = requests.get(f"https://api.weather.com/v1/{city}") return resp.json() def test_weather(mocker): mock_resp = mocker.Mock() mock_resp.json.return_value = {"city": "shenzhen", "temperature": 28} mocker.patch("requests.get", return_value=mock_resp) assert get_weather("shenzhen")["temperature"] == 28

这里mocker.patch("requests.get", return_value=mock_resp)是关键：你在测试里把requests.get换成 mock，被测代码里的requests.get用的就是同一个替换后的对象。这就是为什么“接口自动化里 mock 第三方接口”这么简单粗暴：requests 是个全局对象，patch 掉它的 get 方法，所有调用就都走 mock 了。

更贴近真实项目的场景是：被测接口依赖另一个内部微服务，但这个微服务在测试环境经常不稳定。这种情况下用 mock 模拟依赖服务的返回值，可以让自动化用例不受上游影响。我自己维护过的一套接口自动化是这么组织的：

1. 先按模块建 fixtures，把常用的依赖 mock 抽象成 fixture 函数。
2. 在用例层通过 fixture 组合，灵活替换不同接口的返回。
3. 在 allure 报告里给每个 mock 打上标签，方便排查是走了 mock 还是真实调用。

还有一个使用细节我必须提：在接口自动化里，mock 返回的 JSON 结构尽量和真实接口保持完全一致，尤其是字段类型。我见过太多 mock 返回{"code": "0"}，真实接口返回{"code": 0}，到了断言阶段才发现类型不匹配，误报了十几条用例。写 mock 数据时，最好先跑一次真实环境抓到真实返回样例，再基于这个结构造数据。

3.4 side_effect 的进阶用法：从固定返回到动态行为

前面提到了 side_effect 的三种形态，这里单独拿一小节来说，因为它几乎是 mock 进阶的分水岭。很多复杂的测试场景，一句话就能用 side_effect 搞定。

模拟“第一次调用抛超时，第二次调用成功”的代码写成：

mock_request.side_effect = [ TimeoutError("first timeout"), {"code": 0, "data": "retry success"}, ]

模拟“根据传入参数返回不同结果”，可以写成函数：

def side_effect(url, **kwargs): if "login" in url: return {"token": "abc123"} if "profile" in url: return {"name": "demo", "role": "admin"} return {"code": 404} mock_api.get.side_effect = side_effect

还有更复杂一点的场景：某个函数内部连续调用同一 mock 多次，你想对每次调用做不同的响应，可以用带调用计数器的函数：

call_count = 0 def dynamic_response(*args, **kwargs): nonlocal call_count call_count += 1 if call_count == 1: return {"status": "pending"} return {"status": "done"}

我看过不少测试代码为了这种场景硬写了 if/else 去判断mock_obj.call_count，其实完全没有必要，side_effect 函数本身接收参数，你在函数内部用参数判断逻辑才是更优雅的方案。

3.5 复杂调用链的多层 mock：一个用例涉及多个协作者

真实项目里一个函数常常依赖四五个协作者：一个缓存、一个数据库、一个消息队列、一个外部 API。写测试时如果全都靠@patch装饰器一层层叠，函数签名会变成：

@patch("module_a.cache.Redis") @patch("module_a.db.Session") @patch("module_a.mq.Producer") @patch("module_a.api.PaymentClient") def test_big_flow(mock_pay, mock_mq, mock_db, mock_cache):

这种代码读起来不仅累，而且装饰器顺序稍微搞错，参数位置就全乱了。我的经验是不要贪图这种“一步到位”的写法，改用 fixture 组合：

@pytest.fixture def mock_redis(mocker): return mocker.patch("module_a.cache.Redis") @pytest.fixture def mock_db(mocker): return mocker.patch("module_a.db.Session") @pytest.fixture def mock_pay(mocker): mocker.patch("module_a.api.PaymentClient.charge", return_value={"code": 0}) return mocker def test_big_flow(mock_redis, mock_db, mock_pay): result = big_service.run() assert result["status"] == "success"

这样一来，测试函数签名清爽了，每个 fixture 也可以单独复用到其他测试里。而且我建议在 fixture 内部直接配置好默认 return_value，这样测试函数里只需要关注对返回值的断言，不用再重复设置 mock 行为。只有少数特殊用例才需要覆盖 fixture 的默认值，可以用mocker.patch在测试内部二次拦截。

还有一种场景是“一个 mock 对象要被多个被测对象引用”，比如redis_client同时用在 service 和 repository 两个模块里。这时候比较稳妥的做法是在 conftest.py 里定义 session 级别的 fixture，确保整个测试会话只创建一个 mock 对象，再把这个 mock 对象同时注入到所有被测模块里。这样才能保证 service 写入的值和 repository 读到的值用的是同一个 mock 对象，避免“service 调 A mock，repository 读 B mock”这种各自为政的问题。

4. 常见问题与排查技巧实录：那些最容易让你怀疑人生的坑

4.1 Mock 相关的 10 个高频问题速查表

我在带团队和帮同事 review 测试代码的过程中，总结了下面这些高频问题，做成速查表，方便你随时翻：

4.2 排查“mock 没生效”的标准化流程

我每次遇到 mock 不生效，都会按下面这套流程排查，基本能定位到 90% 的问题：

第一步，确认 patch 的路径。路径不是“类定义的地方”，而是“被测代码里调用时所在模块的命名空间”。举个例子：被测文件src/order.py里写了from utils.wechat import WechatPay，那 patch 就要写patch("src.order.WechatPay")，而不是patch("utils.wechat.WechatPay")。

第二步，确认被测代码确实 import 了同一个对象。如果被测代码是import utils.wechat再调用utils.wechat.WechatPay()，那你 patchutils.wechat.WechatPay是可行的；但如果被测代码是from utils.wechat import WechatPay，那它已经把引用绑定到了自己的命名空间，必须 patchorder.WechatPay。

第三步，在 mock 上临时加一个副作用来验证是否生效。比如：

mock_obj.side_effect = AssertionError("mock is working")

如果测试抛出了这个异常，说明 mock 生效了；如果没抛，说明被测路径根本没调用到这里。

第四步，检查是不是在 import 时对象就已被提前创建。有些代码在模块顶层就client = WechatPay()，后面所有方法都调这个模块级 client。这时候 mock 类本身没用，得直接patch("order.client")，或者用patch.object(order, "client")。

这套流程看着简单，但真排查起来非常省时间。我见过太多人卡在第三步就放弃了，直接在群里问“为什么 mock 没生效”，其实只要加一行side_effect = AssertionError就能验证。

4.3 避免“测试全在测自己编的故事”

这个坑不是技术问题，而是方法论问题。mock 用得越多，测试离真实行为越远，最后可能出现“所有测试都绿，但一上线就挂”的极端情况。

我的建议是要明确 mock 的边界：

第一，单元测试里 mock 外部依赖没问题，但核心业务逻辑尽量不要 mock。比如金额计算、状态转换、权限判断这些关键规则，应该用真实对象和真实数据去测，mock 只负责隔离 IO。

第二，接口自动化里的 mock，尽量只用在下游不稳定或不可控的场景。能走测试环境的真实依赖，就不要 mock。比如测试环境本来就有 MySQL、Redis 这些基础设施，用真实的服务去跑集成逻辑，比 mock 出来更可靠。

第三，mock 的返回数据要定期和真实接口对齐。我在项目里会建一个“mock 数据基线”，每次真实接口的返回结构有变更，就同步更新 mock 数据，并且用断言卡字段类型，避免 mock 和真实接口脱节。

说到底，mock 是一把手术刀，用得好可以精准切除测试里的外部依赖，用不好就会把病灶整个挡住，让测试变成一个“自嗨工具”。我始终相信一句话：mock 是为了让测试更稳定，而不是让测试失去灵魂。

5. 工程落地与团队协作建议：把 Mock 变成日常测试基础设施

5.1 配置开关：一条命令切换 mock 与真实环境

在团队协作里，最怕的不是某个人不会写 mock，而是不同环境、不同人的本地配置各不相同，导致同一套用例结果不一致。针对这个问题，我推过一套基于环境变量的 mock 开关方案，效果蛮明显。

实现思路很简单：在 conftest.py 里读取一个环境变量，比如MOCK_ENABLED，当它等于1时才自动加载 mock fixtures；否则走真实依赖。

import os import pytest @pytest.fixture(autouse=True) def auto_mock(mocker): if os.environ.get("MOCK_ENABLED", "0") == "1": mocker.patch("module_a.api.PaymentClient.charge", return_value={"code": 0}) mocker.patch("module_a.mq.Producer.send", return_value=True)

这样本地开发时默认不开 mock，遇到外部依赖问题可以手动开启；CI 环境里按需开启。单个用例需要特殊 mock 时，再显式覆盖。这种“默认真实，按需 mock”的方式，避免了一整套测试都活在 mock 世界里。

5.2 conftest.py 的组织方式与 mock 命名规范

conftest.py 是 pytest 的 fixture 集中地，也是 mock 管理的最佳位置。我习惯把常用 mock 分成三类：

第一类，基础环境类。比如环境变量、全局配置、日志对象。这一类几乎对所有测试都有影响，用autouse=True的 fixture 全局加载。

第二类，业务依赖类。比如外部 API 客户端、数据库 Session、Redis。这类在每个模块测试里按需引用。

第三类，定制行为类。比如某个用例要模拟接口超时、异常、慢响应。这类只写在具体测试文件里，不放到全局。

命名上，我建议用mock_xxx开头，并且在 fixture 内部把 return_value 都设置好，到测试函数里只做断言。另外，conftest.py 里不要塞太多具体用例逻辑，否则文件会变成一个大杂烩，后期没人敢动。

5.3 和 pytest 生态工具整合：allure 报告、超时控制、参数化

Mock 在日常 pytest 工程里不是孤立的，它经常和 allure 报告、pytest-timeout、参数化一起使用。这里分享两个我实际组合使用的场景。

场景一：allure 报告里记录“当前用例 mock 了哪些依赖”。做法很简单，fixture 里给 allure 动态加标签：

import allure import pytest @pytest.fixture def mock_payment(mocker): mocker.patch("module_a.api.PaymentClient.charge", return_value={"code": 0}) allure.dynamic.tag("mock:payment") yield

在报告里你能一眼看到这条用例依赖了哪些 mock，排查“为什么这个环境没过”时非常有帮助。

场景二：参数化测试里复用 mock 配置。比如登录接口有十几种失败场景，每种异常都要 mock 不同的返回：

@pytest.mark.parametrize( "error_code, expected_msg", [ (1001, "user not found"), (1002, "password error"), (1003, "banned"), ], ) def test_login_fail(mocker, error_code, expected_msg): mocker.patch("module_a.api.AuthService.login", return_value={"code": error_code, "msg": expected_msg}) resp = login_api.login("demo", "123456") assert resp["msg"] == expected_msg

这套组合拳在实际项目中非常常用：参数化负责覆盖场景，mock 负责隔离依赖，allure 负责可观测性，三个工具一配合，测试用例的维护成本会降低许多。

5.4 常见工程坑：mock 数据版本管理

最后说一个在“多人协作”场景下特别容易被忽视的问题：mock 数据的版本管理。接口结构变更了，mock 数据没更新，测试一样是基于错误的契约在验证。如果你发现某个模块的测试一直绿，但线上接口早就变了，大概率就是 mock 数据没有同步。

我目前的解决方法是：

1. 把常用的 mock 返回数据抽成独立的 JSON 或 Python dict，放在 tests/mock_data/ 目录下。
2. 在测试里用固定的 fixture 加载这些数据，而不是散落在各个测试函数里。
3. 每次真实接口变更，走正常的 review 流程更新 mock_data 文件和对应的契约测试。

这么做的好处是，mock 数据基线可以被检查、被审计，不会出现一个人改了一个接口结构，其他同事的测试全挂在老 mock 数据上的情况。

我个人在实际操作中的一个体会是，Mock 看起来是一个“小技巧”，但真正把它用对、用好，需要从方法论和工程层面一起发力。如果只是把 Mock 当作“造假数据”，你会很快遇到边界问题；如果你能把 mock 边界划清楚、把 fixture 组织好、把数据版本管理起来，pytest 的测试体系会变得非常稳定且好维护。最后再分享一个小技巧：每次写 mock 之前，先想一想“如果这里不 mock，真实环境会发生什么”，想清楚这个问题，你就知道该 mock 什么、不该 mock 什么了。