本文详解在单元测试中，当目标类在模块导入时即完成实例化（如 legacy = legacyclass()），直接使用 @patch 修饰类无法生效的根本原因，并提供可靠、可复现的解决方案：在导入被测类前动态 patch 类定义，确保 mock 覆盖初始化过程。
在 Python 单元测试中，unittest.mock.patch 是模拟外部依赖的核心工具。但一个常见且隐蔽的陷阱是：当被测类（如 ClassToTest）在模块层级直接实例化了依赖对象（如 self.legacy = LegacyClass() 或类属性 legacy = LegacyClass()），该实例化行为会在模块首次导入时立即执行。此时，若你在测试类上使用 @patch('my_module.LegacyClass')，mock 实际发生在实例化之后——LegacyClass 已经被真实构造并赋值完毕，后续对 legacy_mock.get_dict 的赋值（如 MagicMock(return_value=...)）仅作用于 mock 类本身，而不会影响早已存在的、真实的 legacy 实例。
因此，原测试失败的本质是时序错误：mock 必须在 LegacyClass() 被调用前就生效，而非之后。
✅ 正确做法：延迟导入 + 上下文内 patch
关键原则是：在 LegacyClass 被导入和实例化之前，先 patch 它。推荐使用 with mock.patch(...): 上下文管理器，并在 patch 生效后才导入被测模块：
Python 编程规范与最佳实践。强制 PEP 8 代码风格、语法校验、单元测试执行，适用于代码编写、审查和重构。触发词：Python、代码规范、py_compile、单元测试。
# test_example.py
import unittest
from unittest import mock
class TestClassToTest(unittest.TestCase):
def test_method_to_test_returns_true(self):
# 在导入 class_to_test 前，先 patch my_module.LegacyClass
with mock.patch('src.my_module.LegacyClass') as LegacyClassMock:
# 此时 LegacyClass 已被 mock，后续导入将使用 Mock 类
from src.class_to_test import ClassToTest
# 配置 mock 实例的行为（注意：操作的是 mock 类生成的实例）
# LegacyClassMock.return_value 是 ClassToTest 中 self.legacy 的实际对象
LegacyClassMock.return_value.get_dict.return_value = {'data': {'value': 1}}
# 创建被测实例
ctt = ClassToTest()
# 断言逻辑正确执行
result = ctt.method_to_test()
self.assertTrue(result)? 核心要点：LegacyClassMock.return_value 代表 ClassToTest 内部创建的 LegacyClass() 实例（即 ctt.legacy），因此必须通过 .return_value.get_dict.return_value 设置其方法返回值，而非直接赋值 LegacyClassMock.get_dict。
⚠️ 常见误区与注意事项
❌ 错误写法：legacy_mock.get_dict = MagicMock(...)
→ 这是在 mock 类 上设置属性，但 ClassToTest 使用的是该类的 实例，实例方法需通过 return_value 链配置。❌ 错误时机：在 import ClassToTest 之后再 patch
→ 实例化已发生，mock 失效。✅ 推荐结构：始终将 patch 放在 import 语句之前，并使用 with 确保作用域隔离。
? 进阶提示：若项目结构复杂，可考虑将被测类重构为支持依赖注入（如 __init__(self, legacy=None)），但这不属于本文“不可修改遗留代码”的前提范围。
总结
模拟已静态实例化的依赖，核心在于控制 patch 的生命周期早于模块导入与类初始化。通过 with mock.patch(): + 延迟导入的组合，既能严格遵守“不修改生产代码”的约束，又能精准控制 mock 行为，确保测试的可靠性与可维护性。这是处理遗留系统集成测试的关键实践之一。
