mock 应仅隔离外部依赖（如数据库、HTTP服务），而非内部逻辑；避免 mock 类构造函数、随意伪造属性；不 mock 纯计算型标准库函数；patch 路径须精准且作用域受限。
mock 适合隔离外部依赖，但不该用于内部逻辑验证
mock 的核心价值是切断测试与真实外部系统（如数据库、HTTP 服务、文件系统、第三方 SDK）的耦合。例如调用 requests.get 时，用 @patch('requests.get') 返回预设响应，就能避免网络请求失败或数据变动影响测试稳定性。但若对被测函数内部的一个私有辅助方法（如 _calculate_score()）打桩，就违背了单元测试初衷——你本该通过输入输出验证它的行为，而不是跳过它。mock 此处不仅掩盖逻辑缺陷，还让测试失去对实际执行路径的覆盖。
避免 mock 类的构造函数或过度 stub 属性
当需要测试一个类的实例方法时，常见误区是 mock 整个类：MyService = Mock()。这会导致你完全绕过初始化逻辑（如 __init__ 中的参数校验、资源预热），测试对象已不是真实类型。更合理的方式是：实例化真实类，仅对它依赖的协作对象 mock。比如 service = MyService(db=Mock())，既保留自身结构，又隔离 db 行为。同理，不要用 mock_obj.attr = 'fake' 随意伪造状态；应通过 mock 的 return_value 或 side_effect 控制方法调用结果，让交互更贴近真实调用契约。
不 mock 标准库中纯计算型函数
像 math.sqrt、json.loads、datetime.now 这类无副作用、确定性高的函数，mock 它们通常得不偿失。mock datetime.now 是合理的（因时间不可控），但 mock math.pow 就没必要——它不引入不确定性，mock 反而增加测试维护成本，且无法发现你是否误用了参数类型或边界值。真正该关注的是：你的代码是否在正确时机调用它、传入的参数是否符合预期。这时用 assert 调用断言（如 mock_pow.assert_called_with(2, 3)）比 mock 返回值更有意义。
警惕 patch 范围过大导致的“假成功”
@patch 的位置必须精准对应被测代码中导入/使用的路径。常见错误是 patch 了模块 A 中的函数，但被测代码实际从模块 B 导入并使用——patch 失效，测试运行的是真实函数。另一个问题是 patch 跨测试污染：未正确 stop 或使用作用域管理（如 with patch(...)），导致后续测试读取到被篡改的全局状态。建议优先使用上下文管理器或 pytest 的 fixture（如 monkeypatch），确保 patch 严格限定在单个测试内生效。
立即学习“Python免费学习笔记（深入）”；
