在 Python 单元测试中，使用 mockito 模拟方法失败，通常并非语法错误，而是由于未能在被测模块的命名空间内正确打补丁——关键在于必须模拟被测类实际引用的函数路径（例如，在类中通过from models.crud import get_plane_by_id导入后直接调用的get_plane_by_id），而非函数原始的模块定义位置。
你是否在 Python 单元测试中遇到过这样的困扰？明明已经使用 mockito 将某个函数“替换”为模拟对象，但运行测试时，程序依然固执地执行了原始的函数实现。代码语法检查一切正常，但模拟操作却完全失效。
问题的根源往往不在于代码错误，而在于“打补丁”的目标位置选择不当。核心原则是：你必须模拟被测模块实际调用时所使用的那个函数引用，而不是函数最初被定义的那个源模块路径。
问题的根源：深入理解 Python 的导入机制与命名空间
这一现象的背后，是 Python 独特的导入与命名空间绑定机制。让我们通过一个具体案例来剖析：假设你的被测类 PersistAircraftEvents 定义在 services/aircraft.py 文件中，并且文件顶部有如下导入语句：
from models.crud import get_plane_by_id, create_plane
当这行代码执行时，Python 会将 models.crud 模块中的 get_plane_by_id 函数对象绑定到当前模块 services.aircraft 的局部命名空间。此后，在 PersistAircraftEvents 类内部，任何对 get_plane_by_id(...) 的调用，实际上指向的都是 services.aircraft.get_plane_by_id 这个本地引用，而不再是 models.crud.get_plane_by_id。
因此，如果你在测试中尝试模拟 models.crud.get_plane_by_id，就等于在错误的地址进行拦截，自然无法捕获到实际发生的函数调用。
✅ 正确的解决方案：在被测模块的命名空间中进行模拟
正确的思路是：定位到函数被实际调用的命名空间，并在该处进行打补丁操作。具体实现步骤如下：
from mockito import when, unstub
from services.aircraft import PersistAircraftEvents # ✅ 导入被测类
import services.aircraft # ✅ 关键步骤！导入其所在的模块
class TestPersistAircraftEvents:
def test_unknown_aircraft_type(self):
db = mock()
service = PersistAircraftEvents(db)
event = ReceivedAircraftEvent(
event_time=datetime.now(),
aircraft_id="what?",
event_type="test"
)
# ✅ 精准模拟在 services.aircraft 模块中导入的那个函数引用
when(services.aircraft).get_plane_by_id(...).thenReturn(None)
try:
service.persist_aircraft_event(event)
# 在此处添加你的断言逻辑...
finally:
unstub() # 清理 mock，确保测试隔离性
请注意其中的关键：通过 import services.aircraft 导入模块，然后针对 services.aircraft.get_plane_by_id 进行模拟。这才是被测类在执行时所看到的函数对象。
⚠️ 常见误区与最佳实践要点
为了更清晰地掌握这一技巧，我们对比几个典型的错误模式与正确做法：
- ❌ 错误路径：
when(models.crud).get_plane_by_id(...)。这修改的是源模块，但调用发生在另一个独立的命名空间内，因此模拟无效。 - ❌ 重复导入陷阱：先执行
from models.crud import get_plane_by_id，再尝试通过import models.crud来模拟后者。这依然无效，因为第一次导入已经创建了一个独立的本地引用。 - ✅ 正确做法：务必导入被测类所在的模块（本例为
services.aircraft），并对其内部的函数引用进行打补丁。 - ✅ 保持测试隔离性：使用
unstub()（建议置于finally代码块中）来清理模拟对象，这在如 pytest 等测试用例共享进程上下文的框架中至关重要。
