1. 项目概述为什么需要定制你的Mock测试环境在写后端接口或者前端调用逻辑的时候你肯定遇到过这种场景依赖的第三方服务挂了或者某个下游模块还没开发完但你的代码逻辑必须得测。这时候如果傻等着项目进度就卡住了。Mock技术就是来解决这个“卡脖子”问题的。它允许你在测试中模拟这些外部依赖的行为让你的测试用例能够独立、快速地运行起来。pytest-mock并不是一个独立的、需要额外安装的库它是pytest框架内置的一个强大插件fixture通常以mocker或mock这个fixture的形式提供。它本质上是对Python标准库unittest.mock的集成和增强让你在pytest的生态里用起来更顺手。所以当我们谈“配置”pytest-mock时更多是在谈如何利用好pytest的机制和unittest.mock的功能来搭建一个高效、可维护的Mock测试环境。这个环境不是一成不变的。不同的项目、不同的测试场景对Mock的需求差异很大。比如你可能只想模拟一个函数调用的返回值也可能需要模拟一个类并检查它的方法是否被以特定参数调用甚至需要模拟一个上下文管理器或者异步函数。一个“定制化”的Mock环境意味着你能根据当前测试用例的精准需求灵活、清晰、不引入副作用地使用Mock而不是写出一堆难以理解和维护的“魔术代码”。2. 核心思路理解pytest-mock的工作机制与配置哲学在深入具体配置之前我们必须先理清pytest-mock的核心工作方式。这有助于我们理解后续所有“配置”动作的意图。2.1 mocker fixture你的Mock指挥棒pytest-mock的核心是一个名为mocker的pytest fixture。你可以在你的测试函数中直接使用它def test_some_function(mocker): # 现在你可以使用 mocker 来创建各种 Mock 对象了 mock_obj mocker.Mock()这个mocker对象是pytest-mock插件提供的它内部封装了unittest.mock的主要功能并增加了一些pytest友好的特性比如自动清理。最重要的一点是在每个测试函数执行完毕后mocker所做的所有打补丁patch操作都会被自动撤销。这是相比于直接使用unittest.mock的一个巨大优势避免了测试之间的相互污染。2.2 配置的层次从临时打补丁到全局策略“定制Mock环境”可以从几个层面来理解用例级配置针对单个测试函数使用mocker.patch等方法来模拟特定对象。这是最常用、最灵活的层面。模块/类级配置在conftest.py中定义自定义fixture封装一组常用的Mock逻辑供多个测试函数复用。项目级配置通过pytest的配置文件如pytest.ini或插件定义一些全局的Mock行为或约定。例如自动对某些特定路径的导入进行Mock。我们通常所说的“配置指南”主要聚焦在前两个层面尤其是如何高效、安全地进行用例级和模块级的Mock。2.3 明确Mock的边界什么该Mock什么不该Mock这是定制环境前最重要的决策。一个基本原则是只Mock外部依赖和不稳定的依赖不要Mock你正在测试的代码单元内部的其他部分。该Mock的数据库连接、第三方API调用requests, boto3等、网络请求、文件系统操作、时间函数time.time,datetime.now、随机数生成器random等。不该Mock的你正在测试的那个函数或类内部的纯计算逻辑、数据转换等。Mock这些会让你测试失去意义。3. 核心配置技巧与实操要点接下来我们进入实战环节。我会结合常见场景展示如何利用pytest-mock进行精细化配置。3.1 基础打补丁mocker.patch的三种姿势mocker.patch是使用频率最高的方法用于临时替换一个对象。关键是要找对“目标对象”。场景一Mock一个模块中的函数假设我们有一个utils.py模块里面有一个调用外部API的函数call_external_api。# utils.py import requests def call_external_api(url): response requests.get(url) return response.json() if response.status_code 200 else None def process_data(): data call_external_api(https://api.example.com/data) # ... 处理 data 的逻辑 return processed_result我们要测试process_data但不想真的发起网络请求。# test_utils.py def test_process_data_success(mocker): # 1. 模拟 utils.call_external_api 这个函数 # 注意目标是 utils.call_external_api因为我们要在 utils 模块内部替换它 mock_api mocker.patch(utils.call_external_api) # 2. 配置这个模拟函数的返回值 mock_api.return_value {key: mocked_value} # 3. 执行测试 from utils import process_data result process_data() # 4. 断言结果和行为 assert result expected_result_based_on_mocked_data # 断言模拟函数被调用了一次且没有参数因为在process_data里调用时没传参 mock_api.assert_called_once_with(https://api.example.com/data)注意patch的字符串参数必须是“目标对象在测试执行时的引用路径”。因为process_data内部调用的是call_external_api而这个函数在utils模块的命名空间里所以我们要patchutils.call_external_api。如果直接patchrequests.get也可以但那样就Mock了更底层的依赖粒度更细但有时不如直接Mock业务函数清晰。场景二Mock一个类及其方法假设我们依赖一个外部服务类ExternalService。# services.py class ExternalService: def __init__(self, api_key): self.api_key api_key def fetch_item(self, item_id): # 复杂的网络交互 pass def update_item(self, item_id, data): pass在测试中我们可能想模拟这个类的实例或者模拟它的某个方法。# test_my_module.py def test_using_external_service(mocker): # 方法1Mock整个类返回一个Mock实例 MockServiceClass mocker.patch(services.ExternalService) # 此时任何创建 ExternalService 的地方得到的都是同一个 Mock 对象 mock_instance MockServiceClass.return_value mock_instance.fetch_item.return_value {id: 1, name: Mocked Item} # 方法2只Mock类的某个方法更精确 mock_fetch mocker.patch(services.ExternalService.fetch_item) mock_fetch.return_value {id: 1, name: Mocked Item} # ... 调用被测代码它会使用被Mock过的类或方法场景三Mock一个对象的属性有时你需要Mock一个实例的某个属性。def test_mock_attribute(mocker): class SomeClass: property def expensive_value(self): # 耗时的计算或IO return 42 obj SomeClass() # 直接patch这个实例的属性 mocker.patch.object(obj, expensive_value, return_value100) assert obj.expensive_value 1003.2 高级配置控制Mock对象的行为简单的return_value和side_effect是基础但远不止于此。1. 使用 side_effect 实现复杂行为side_effect可以是一个函数、一个可迭代对象或一个异常。def test_mock_with_side_effect(mocker): mock_func mocker.Mock() # 1. side_effect 为函数根据输入动态返回 def dynamic_return(arg): return arg * 2 mock_func.side_effect dynamic_return assert mock_func(5) 10 # 2. side_effect 为可迭代对象如列表依次返回值 mock_func.side_effect [10, 20, 30] assert mock_func() 10 assert mock_func() 20 assert mock_func() 30 # 3. side_effect 为异常模拟调用失败 mock_func.side_effect ConnectionError(Network failed) with pytest.raises(ConnectionError): mock_func()2. 配置 Mock 的调用断言Mock对象自动记录了每次调用的信息便于断言。def test_mock_assertions(mocker): mock_func mocker.patch(some_module.func) # 被测代码调用了 func some_module.func(first, arg2value) some_module.func(second) # 断言 mock_func.assert_called() # 至少被调用一次 mock_func.assert_called_once() # 只被调用一次如果上面调用了两次这个会失败 mock_func.assert_called_with(first, arg2value) # 最近一次调用的参数 mock_func.assert_any_call(second) # 曾经以这些参数被调用过 assert mock_func.call_count 2 # 查看调用历史 assert mock_func.call_args_list [ mocker.call(first, arg2value), mocker.call(second) ]3. 使用 mocker.spy 进行“监视”而非“替换”有时你不想改变一个函数的行为只想看看它是否被调用、如何被调用。这时可以用spy。def test_with_spy(mocker): from utils import process_data # spy 会包裹原函数原函数逻辑依然执行 spy_func mocker.spy(utils, call_external_api) result process_data() # 这里会真实调用 call_external_api如果没被其他patch影响 spy_func.assert_called_once() # 你仍然可以获取调用参数但函数执行了真实逻辑3.3 组织与复用在conftest.py中定义Mock Fixture当多个测试文件都需要Mock同一个复杂依赖时将其封装到conftest.py的自定义fixture中是最佳实践。# conftest.py import pytest import pytest_mock pytest.fixture def mock_external_api(mocker): 提供一个模拟了外部API的fixture # 假设我们项目里常用一个叫 api_client 的模块 mock_get_data mocker.patch(api_client.get_data) # 预设一个通用的成功响应 mock_get_data.return_value {status: ok, data: []} # 返回这个mock对象方便测试用例进一步定制 return mock_get_data pytest.fixture def mock_database_session(mocker): 模拟数据库会话 mock_session mocker.MagicMock() # MagicMock 支持更多魔术方法 mock_commit mocker.patch(database.Session.commit) mock_rollback mocker.patch(database.Session.rollback) # 返回一个包含相关mock的字典 return { session: mock_session, commit: mock_commit, rollback: mock_rollback }然后在测试中直接使用# test_my_service.py def test_service_logic(mock_external_api, mock_database_session): # 可以直接使用预设的mock result my_service_function() mock_external_api.assert_called_once() # 也可以在测试中临时覆盖fixture中的返回值 mock_external_api.return_value {status: ok, data: [{id: 1}]} result2 my_service_function() assert result2 something_specific这种方式将Mock的设置逻辑与使用逻辑分离让测试用例更清晰也便于统一维护Mock行为。4. 实战构建一个定制的异步Mock测试环境现代Python开发中异步IO很常见。Mock异步函数需要一点特别的处理。4.1 Mock异步函数async def对于用async def定义的协程函数你需要让Mock也返回一个可等待对象Awaitable。最简单的方法是使用mocker.AsyncMock。import pytest async def test_async_mock(mocker): # 模拟一个异步函数 mock_async_fetch mocker.patch(async_module.fetch_data, new_callablemocker.AsyncMock) # 配置返回值 mock_async_fetch.return_value {id: 1} # 在测试中调用注意测试函数本身也是async的 result await async_module.fetch_data(some_url) assert result {id: 1} mock_async_fetch.assert_awaited_once_with(some_url) # 注意断言方法是 assert_awaited_*4.2 在同步测试中Mock异步依赖如果你的被测代码是同步的但它内部调用了异步函数例如通过asyncio.run你依然可以Mock那个异步函数但Mock对象本身不必是AsyncMock因为它是在同步上下文中被调用的最终会由事件循环处理。不过更清晰的做法是Mock掉整个异步上下文。def test_sync_code_calling_async(mocker): # 假设内部调用了 asyncio.run(some_async_func()) # 我们可以直接Mock some_async_func让它返回一个普通值 # 因为 asyncio.run 会处理协程 mocker.patch(async_module.some_async_func, return_valuemocked_result) # 也可以Mock asyncio.run 本身让它直接返回我们想要的值跳过异步执行 mock_run mocker.patch(asyncio.run) mock_run.return_value direct_mocked_result result my_sync_function() assert result direct_mocked_result4.3 配置一个通用的异步Mock Fixture对于频繁使用的异步客户端如aiohttp.ClientSession,aioredis.Redis在conftest.py中创建fixture非常有用。# conftest.py import pytest pytest.fixture def mock_aiohttp_client(mocker): 模拟 aiohttp.ClientSession 的post/get方法 # 创建一个异步Mock的session mock_session mocker.AsyncMock(spec[get, post, close]) # 创建一个异步Mock的response mock_response mocker.AsyncMock() mock_response.status 200 mock_response.json.return_value {message: success} # 设置session.get的返回值为这个response mock_session.get.return_value.__aenter__.return_value mock_response # 替换掉创建session的地方 mocker.patch(aiohttp.ClientSession, return_valuemock_session) return mock_session, mock_response # 返回以便测试用例进一步定制5. 常见陷阱、问题排查与最佳实践即使理解了原理在实际配置Mock环境时还是会踩坑。下面是我总结的一些高频问题和技巧。5.1 坑1Patch目标路径错误Import Error这是最常见的问题。mocker.patch的第一个参数是字符串它必须指向被测代码中引用目标对象的地方。症状测试运行时Mock似乎没生效或者报AttributeError/ImportError。排查确认你patch的模块路径是否正确。在Python中import module和from package import module会影响patch路径。使用print或调试器查看在测试执行时目标函数/类是从哪里被引用的。记住黄金法则Patch where the object is used, not where it is defined.如果my_module里写了from utils import call_external_api那么在测试my_module中的函数时应该patchmy_module.call_external_api而不是utils.call_external_api。因为前者是my_module内部使用的命名空间。5.2 坑2Mock对象生命周期管理混乱症状一个测试用例的Mock影响了另一个测试用例导致测试结果不稳定。解决始终使用mockerfixture提供的patch方法不要直接使用unittest.mock.patch作为装饰器或上下文管理器除非你非常清楚自己在做什么。mocker会自动管理清理。如果必须在setUp(或setup_method) 中手动patch确保在tearDown中stop所有patch。5.3 坑3过度Mock或Mock了不该Mock的东西症状测试变成了“自说自话”失去了验证真实逻辑的意义。测试覆盖率很高但代码一改就崩。原则只Mock外部边界如网络、磁盘、数据库、时间、随机数、第三方服务客户端。不Mock内部实现你正在测试的单元内部的私有函数、辅助函数。如果发现需要Mock很多内部东西才能测试可能是代码结构需要重构职责过重的信号。考虑使用Fake对象对于一些复杂的依赖如内存数据库创建一个轻量级的、行为真实的Fake对象Fake Repository比用Mock配置一堆返回值更可靠、更易于维护。5.4 最佳实践清单命名清晰Mock变量名要有意义如mock_requests_get,mock_db_session避免用mock1,mock2。配置前置在测试函数的开头就完成所有Mock的创建和返回值配置让“测试准备”阶段一目了然。断言行为而不仅仅是状态除了检查返回值多用assert_called_with等方法来验证模块间的协作是否符合预期。使用spec或autospec在Mock类或对象时使用mocker.patch(..., autospecTrue)或mocker.Mock(specRealClass)。这会让Mock对象只拥有原始对象的属性和方法如果你不小心调用了不存在的方法测试会立刻失败避免了因API变更而导致的虚假通过的测试。# 更好的做法 mock_service mocker.patch(services.ExternalService, autospecTrue) # mock_service.non_existent_method() # 这会引发 AttributeError帮助发现错误将复杂Mock逻辑提取到Fixture中如前所述这是保持测试代码DRYDon‘t Repeat Yourself和可维护性的关键。为Mock编写独立的测试如果你的Mock Fixture或Mock对象本身逻辑很复杂例如一个模拟了多种状态机的Fake考虑为它单独写测试确保其行为符合预期。定制你的pytest-mock环境本质上是在定制一套高效、可靠的测试策略。它没有唯一的“标准答案”但遵循“明确边界、精细控制、良好组织”的原则就能构建出与项目共同演进的、强大的Mock测试基础设施。记住Mock是手段不是目的最终目标是让测试更快、更稳定、更有信心地保障代码质量。
1. 项目概述为什么需要定制你的Mock测试环境在写后端接口或者前端调用逻辑的时候你肯定遇到过这种场景依赖的第三方服务挂了或者某个下游模块还没开发完但你的代码逻辑必须得测。这时候如果傻等着项目进度就卡住了。Mock技术就是来解决这个“卡脖子”问题的。它允许你在测试中模拟这些外部依赖的行为让你的测试用例能够独立、快速地运行起来。pytest-mock并不是一个独立的、需要额外安装的库它是pytest框架内置的一个强大插件fixture通常以mocker或mock这个fixture的形式提供。它本质上是对Python标准库unittest.mock的集成和增强让你在pytest的生态里用起来更顺手。所以当我们谈“配置”pytest-mock时更多是在谈如何利用好pytest的机制和unittest.mock的功能来搭建一个高效、可维护的Mock测试环境。这个环境不是一成不变的。不同的项目、不同的测试场景对Mock的需求差异很大。比如你可能只想模拟一个函数调用的返回值也可能需要模拟一个类并检查它的方法是否被以特定参数调用甚至需要模拟一个上下文管理器或者异步函数。一个“定制化”的Mock环境意味着你能根据当前测试用例的精准需求灵活、清晰、不引入副作用地使用Mock而不是写出一堆难以理解和维护的“魔术代码”。2. 核心思路理解pytest-mock的工作机制与配置哲学在深入具体配置之前我们必须先理清pytest-mock的核心工作方式。这有助于我们理解后续所有“配置”动作的意图。2.1 mocker fixture你的Mock指挥棒pytest-mock的核心是一个名为mocker的pytest fixture。你可以在你的测试函数中直接使用它def test_some_function(mocker): # 现在你可以使用 mocker 来创建各种 Mock 对象了 mock_obj mocker.Mock()这个mocker对象是pytest-mock插件提供的它内部封装了unittest.mock的主要功能并增加了一些pytest友好的特性比如自动清理。最重要的一点是在每个测试函数执行完毕后mocker所做的所有打补丁patch操作都会被自动撤销。这是相比于直接使用unittest.mock的一个巨大优势避免了测试之间的相互污染。2.2 配置的层次从临时打补丁到全局策略“定制Mock环境”可以从几个层面来理解用例级配置针对单个测试函数使用mocker.patch等方法来模拟特定对象。这是最常用、最灵活的层面。模块/类级配置在conftest.py中定义自定义fixture封装一组常用的Mock逻辑供多个测试函数复用。项目级配置通过pytest的配置文件如pytest.ini或插件定义一些全局的Mock行为或约定。例如自动对某些特定路径的导入进行Mock。我们通常所说的“配置指南”主要聚焦在前两个层面尤其是如何高效、安全地进行用例级和模块级的Mock。2.3 明确Mock的边界什么该Mock什么不该Mock这是定制环境前最重要的决策。一个基本原则是只Mock外部依赖和不稳定的依赖不要Mock你正在测试的代码单元内部的其他部分。该Mock的数据库连接、第三方API调用requests, boto3等、网络请求、文件系统操作、时间函数time.time,datetime.now、随机数生成器random等。不该Mock的你正在测试的那个函数或类内部的纯计算逻辑、数据转换等。Mock这些会让你测试失去意义。3. 核心配置技巧与实操要点接下来我们进入实战环节。我会结合常见场景展示如何利用pytest-mock进行精细化配置。3.1 基础打补丁mocker.patch的三种姿势mocker.patch是使用频率最高的方法用于临时替换一个对象。关键是要找对“目标对象”。场景一Mock一个模块中的函数假设我们有一个utils.py模块里面有一个调用外部API的函数call_external_api。# utils.py import requests def call_external_api(url): response requests.get(url) return response.json() if response.status_code 200 else None def process_data(): data call_external_api(https://api.example.com/data) # ... 处理 data 的逻辑 return processed_result我们要测试process_data但不想真的发起网络请求。# test_utils.py def test_process_data_success(mocker): # 1. 模拟 utils.call_external_api 这个函数 # 注意目标是 utils.call_external_api因为我们要在 utils 模块内部替换它 mock_api mocker.patch(utils.call_external_api) # 2. 配置这个模拟函数的返回值 mock_api.return_value {key: mocked_value} # 3. 执行测试 from utils import process_data result process_data() # 4. 断言结果和行为 assert result expected_result_based_on_mocked_data # 断言模拟函数被调用了一次且没有参数因为在process_data里调用时没传参 mock_api.assert_called_once_with(https://api.example.com/data)注意patch的字符串参数必须是“目标对象在测试执行时的引用路径”。因为process_data内部调用的是call_external_api而这个函数在utils模块的命名空间里所以我们要patchutils.call_external_api。如果直接patchrequests.get也可以但那样就Mock了更底层的依赖粒度更细但有时不如直接Mock业务函数清晰。场景二Mock一个类及其方法假设我们依赖一个外部服务类ExternalService。# services.py class ExternalService: def __init__(self, api_key): self.api_key api_key def fetch_item(self, item_id): # 复杂的网络交互 pass def update_item(self, item_id, data): pass在测试中我们可能想模拟这个类的实例或者模拟它的某个方法。# test_my_module.py def test_using_external_service(mocker): # 方法1Mock整个类返回一个Mock实例 MockServiceClass mocker.patch(services.ExternalService) # 此时任何创建 ExternalService 的地方得到的都是同一个 Mock 对象 mock_instance MockServiceClass.return_value mock_instance.fetch_item.return_value {id: 1, name: Mocked Item} # 方法2只Mock类的某个方法更精确 mock_fetch mocker.patch(services.ExternalService.fetch_item) mock_fetch.return_value {id: 1, name: Mocked Item} # ... 调用被测代码它会使用被Mock过的类或方法场景三Mock一个对象的属性有时你需要Mock一个实例的某个属性。def test_mock_attribute(mocker): class SomeClass: property def expensive_value(self): # 耗时的计算或IO return 42 obj SomeClass() # 直接patch这个实例的属性 mocker.patch.object(obj, expensive_value, return_value100) assert obj.expensive_value 1003.2 高级配置控制Mock对象的行为简单的return_value和side_effect是基础但远不止于此。1. 使用 side_effect 实现复杂行为side_effect可以是一个函数、一个可迭代对象或一个异常。def test_mock_with_side_effect(mocker): mock_func mocker.Mock() # 1. side_effect 为函数根据输入动态返回 def dynamic_return(arg): return arg * 2 mock_func.side_effect dynamic_return assert mock_func(5) 10 # 2. side_effect 为可迭代对象如列表依次返回值 mock_func.side_effect [10, 20, 30] assert mock_func() 10 assert mock_func() 20 assert mock_func() 30 # 3. side_effect 为异常模拟调用失败 mock_func.side_effect ConnectionError(Network failed) with pytest.raises(ConnectionError): mock_func()2. 配置 Mock 的调用断言Mock对象自动记录了每次调用的信息便于断言。def test_mock_assertions(mocker): mock_func mocker.patch(some_module.func) # 被测代码调用了 func some_module.func(first, arg2value) some_module.func(second) # 断言 mock_func.assert_called() # 至少被调用一次 mock_func.assert_called_once() # 只被调用一次如果上面调用了两次这个会失败 mock_func.assert_called_with(first, arg2value) # 最近一次调用的参数 mock_func.assert_any_call(second) # 曾经以这些参数被调用过 assert mock_func.call_count 2 # 查看调用历史 assert mock_func.call_args_list [ mocker.call(first, arg2value), mocker.call(second) ]3. 使用 mocker.spy 进行“监视”而非“替换”有时你不想改变一个函数的行为只想看看它是否被调用、如何被调用。这时可以用spy。def test_with_spy(mocker): from utils import process_data # spy 会包裹原函数原函数逻辑依然执行 spy_func mocker.spy(utils, call_external_api) result process_data() # 这里会真实调用 call_external_api如果没被其他patch影响 spy_func.assert_called_once() # 你仍然可以获取调用参数但函数执行了真实逻辑3.3 组织与复用在conftest.py中定义Mock Fixture当多个测试文件都需要Mock同一个复杂依赖时将其封装到conftest.py的自定义fixture中是最佳实践。# conftest.py import pytest import pytest_mock pytest.fixture def mock_external_api(mocker): 提供一个模拟了外部API的fixture # 假设我们项目里常用一个叫 api_client 的模块 mock_get_data mocker.patch(api_client.get_data) # 预设一个通用的成功响应 mock_get_data.return_value {status: ok, data: []} # 返回这个mock对象方便测试用例进一步定制 return mock_get_data pytest.fixture def mock_database_session(mocker): 模拟数据库会话 mock_session mocker.MagicMock() # MagicMock 支持更多魔术方法 mock_commit mocker.patch(database.Session.commit) mock_rollback mocker.patch(database.Session.rollback) # 返回一个包含相关mock的字典 return { session: mock_session, commit: mock_commit, rollback: mock_rollback }然后在测试中直接使用# test_my_service.py def test_service_logic(mock_external_api, mock_database_session): # 可以直接使用预设的mock result my_service_function() mock_external_api.assert_called_once() # 也可以在测试中临时覆盖fixture中的返回值 mock_external_api.return_value {status: ok, data: [{id: 1}]} result2 my_service_function() assert result2 something_specific这种方式将Mock的设置逻辑与使用逻辑分离让测试用例更清晰也便于统一维护Mock行为。4. 实战构建一个定制的异步Mock测试环境现代Python开发中异步IO很常见。Mock异步函数需要一点特别的处理。4.1 Mock异步函数async def对于用async def定义的协程函数你需要让Mock也返回一个可等待对象Awaitable。最简单的方法是使用mocker.AsyncMock。import pytest async def test_async_mock(mocker): # 模拟一个异步函数 mock_async_fetch mocker.patch(async_module.fetch_data, new_callablemocker.AsyncMock) # 配置返回值 mock_async_fetch.return_value {id: 1} # 在测试中调用注意测试函数本身也是async的 result await async_module.fetch_data(some_url) assert result {id: 1} mock_async_fetch.assert_awaited_once_with(some_url) # 注意断言方法是 assert_awaited_*4.2 在同步测试中Mock异步依赖如果你的被测代码是同步的但它内部调用了异步函数例如通过asyncio.run你依然可以Mock那个异步函数但Mock对象本身不必是AsyncMock因为它是在同步上下文中被调用的最终会由事件循环处理。不过更清晰的做法是Mock掉整个异步上下文。def test_sync_code_calling_async(mocker): # 假设内部调用了 asyncio.run(some_async_func()) # 我们可以直接Mock some_async_func让它返回一个普通值 # 因为 asyncio.run 会处理协程 mocker.patch(async_module.some_async_func, return_valuemocked_result) # 也可以Mock asyncio.run 本身让它直接返回我们想要的值跳过异步执行 mock_run mocker.patch(asyncio.run) mock_run.return_value direct_mocked_result result my_sync_function() assert result direct_mocked_result4.3 配置一个通用的异步Mock Fixture对于频繁使用的异步客户端如aiohttp.ClientSession,aioredis.Redis在conftest.py中创建fixture非常有用。# conftest.py import pytest pytest.fixture def mock_aiohttp_client(mocker): 模拟 aiohttp.ClientSession 的post/get方法 # 创建一个异步Mock的session mock_session mocker.AsyncMock(spec[get, post, close]) # 创建一个异步Mock的response mock_response mocker.AsyncMock() mock_response.status 200 mock_response.json.return_value {message: success} # 设置session.get的返回值为这个response mock_session.get.return_value.__aenter__.return_value mock_response # 替换掉创建session的地方 mocker.patch(aiohttp.ClientSession, return_valuemock_session) return mock_session, mock_response # 返回以便测试用例进一步定制5. 常见陷阱、问题排查与最佳实践即使理解了原理在实际配置Mock环境时还是会踩坑。下面是我总结的一些高频问题和技巧。5.1 坑1Patch目标路径错误Import Error这是最常见的问题。mocker.patch的第一个参数是字符串它必须指向被测代码中引用目标对象的地方。症状测试运行时Mock似乎没生效或者报AttributeError/ImportError。排查确认你patch的模块路径是否正确。在Python中import module和from package import module会影响patch路径。使用print或调试器查看在测试执行时目标函数/类是从哪里被引用的。记住黄金法则Patch where the object is used, not where it is defined.如果my_module里写了from utils import call_external_api那么在测试my_module中的函数时应该patchmy_module.call_external_api而不是utils.call_external_api。因为前者是my_module内部使用的命名空间。5.2 坑2Mock对象生命周期管理混乱症状一个测试用例的Mock影响了另一个测试用例导致测试结果不稳定。解决始终使用mockerfixture提供的patch方法不要直接使用unittest.mock.patch作为装饰器或上下文管理器除非你非常清楚自己在做什么。mocker会自动管理清理。如果必须在setUp(或setup_method) 中手动patch确保在tearDown中stop所有patch。5.3 坑3过度Mock或Mock了不该Mock的东西症状测试变成了“自说自话”失去了验证真实逻辑的意义。测试覆盖率很高但代码一改就崩。原则只Mock外部边界如网络、磁盘、数据库、时间、随机数、第三方服务客户端。不Mock内部实现你正在测试的单元内部的私有函数、辅助函数。如果发现需要Mock很多内部东西才能测试可能是代码结构需要重构职责过重的信号。考虑使用Fake对象对于一些复杂的依赖如内存数据库创建一个轻量级的、行为真实的Fake对象Fake Repository比用Mock配置一堆返回值更可靠、更易于维护。5.4 最佳实践清单命名清晰Mock变量名要有意义如mock_requests_get,mock_db_session避免用mock1,mock2。配置前置在测试函数的开头就完成所有Mock的创建和返回值配置让“测试准备”阶段一目了然。断言行为而不仅仅是状态除了检查返回值多用assert_called_with等方法来验证模块间的协作是否符合预期。使用spec或autospec在Mock类或对象时使用mocker.patch(..., autospecTrue)或mocker.Mock(specRealClass)。这会让Mock对象只拥有原始对象的属性和方法如果你不小心调用了不存在的方法测试会立刻失败避免了因API变更而导致的虚假通过的测试。# 更好的做法 mock_service mocker.patch(services.ExternalService, autospecTrue) # mock_service.non_existent_method() # 这会引发 AttributeError帮助发现错误将复杂Mock逻辑提取到Fixture中如前所述这是保持测试代码DRYDon‘t Repeat Yourself和可维护性的关键。为Mock编写独立的测试如果你的Mock Fixture或Mock对象本身逻辑很复杂例如一个模拟了多种状态机的Fake考虑为它单独写测试确保其行为符合预期。定制你的pytest-mock环境本质上是在定制一套高效、可靠的测试策略。它没有唯一的“标准答案”但遵循“明确边界、精细控制、良好组织”的原则就能构建出与项目共同演进的、强大的Mock测试基础设施。记住Mock是手段不是目的最终目标是让测试更快、更稳定、更有信心地保障代码质量。
双梁正问题 【 torch 实战】（Python代码实现）)
