本文深入探讨了在python中使用`pytest-mock`模拟常量时常见的陷阱。当常量通过`from ... import const`导入到另一个模块时，直接对源模块的常量进行打补丁可能无效。文章详细解释了python导入机制导致此问题的原因，并提供了两种有效的解决方案：直接打补丁到使用常量的模块，或延迟导入依赖模块直至打补丁操作完成，确保测试行为符合预期。
理解Python常量导入与Mocking的机制
在Python中进行单元测试时，我们经常需要模拟（Mock）某些依赖项，包括常量。然而，当常量通过from module import CONST语句导入到另一个模块时，直接对源模块的常量进行打补丁（patch）可能无法达到预期效果。这通常是由于Python的导入机制和命名空间工作方式造成的。
考虑以下项目结构：
mod1
├── mod2
│ ├── __init__.py
│ └── utils.py
└── tests
└── test_utils.py其中文件内容如下：
-
mod1/mod2/__init__.py:
立即学习“Python免费学习笔记（深入）”；
CONST = -1
-
mod1/mod2/utils.py:
from mod1.mod2 import CONST # 常量在这里被导入 def mod_function(): print(CONST) -
mod1/tests/test_utils.py:
from mod1.mod2.utils import mod_function import pytest_mock # 通常通过pytest的mocker fixture提供 def test_mod_function_incorrect_patch(mocker): # 尝试打补丁 mod1.mod2.CONST mock = mocker.patch("mod1.mod2.CONST") mock.return_value = 1000 mod_function() # 预期输出1000，实际输出-1
当我们运行pytest并执行test_mod_function_incorrect_patch时，会发现mod_function仍然打印出-1，而不是预期的1000。
原因分析：
- from mod1.mod2 import CONST 的行为： 当utils.py执行from mod1.mod2 import CONST时，它实际上是在utils.py模块的本地命名空间中创建了一个名为CONST的变量，并将其值设置为mod1.mod2.CONST当前的值，即-1。此时，utils.py中的CONST变量已经指向了整型对象-1。
- mocker.patch("mod1.mod2.CONST") 的行为： 随后在测试函数中，mocker.patch("mod1.mod2.CONST")会修改mod1.mod2模块的CONST属性，使其现在指向一个Mock对象（其return_value被设置为1000）。
- 问题所在： mocker.patch修改的是mod1.mod2模块中的CONST。然而，utils.py模块中的CONST变量已经是一个独立的引用，它仍然指向最初导入的整型对象-1。因此，对mod1.mod2.CONST的修改并不会影响到utils.py内部的CONST变量。当mod_function被调用时，它使用的是utils.py命名空间中的CONST，其值依然是-1。
解决方案
要正确地模拟这种通过from ... import ...导入的常量，我们需要确保打补丁操作影响到实际被使用的那个常量引用。有两种主要方法可以实现这一点：
方案一：在常量被使用的模块中打补丁（推荐）
最直接有效的方法是，在常量被实际使用的模块（本例中是mod1.mod2.utils）中对其进行打补丁。这样可以确保我们修改的是mod_function实际引用的那个CONST变量。
# mod1/tests/test_utils.py
from mod1.mod2.utils import mod_function
# import pytest_mock # 通常通过pytest的mocker fixture提供
def test_mod_function_correct_patch_in_usage_module(mocker):
# 打补丁 mod1.mod2.utils.CONST
mock = mocker.patch("mod1.mod2.utils.CONST")
mock.return_value = 1000
mod_function() # 此时将输出 1000原理： mocker.patch("mod1.mod2.utils.CONST")会直接修改mod1.mod2.utils模块命名空间中的CONST变量，使其指向一个Mock对象。由于mod_function直接使用这个命名空间中的CONST，因此它的行为会受到打补丁的影响。
方案二：延迟导入依赖模块
另一种方法是，在mod1.mod2.CONST被打补丁之后，再导入依赖它的模块（mod1.mod2.utils）。这样，当utils.py执行from mod1.mod2 import CONST时，它会导入已经被打补丁的mod1.mod2.CONST，从而在utils.py中绑定到Mock对象。
# mod1/tests/test_utils.py
# 注意：这里不再在文件顶部导入mod_function
# import pytest_mock # 通常通过pytest的mocker fixture提供
def test_mod_function_correct_patch_defer_import(mocker):
# 先打补丁 mod1.mod2.CONST
mock = mocker.patch("mod1.mod2.CONST")
mock.return_value = 1000
# 然后再导入 mod_function
from mod1.mod2.utils import mod_function
mod_function() # 此时也将输出 1000原理： 在from mod1.mod2.utils import mod_function语句执行之前，mod1.mod2.CONST已经被替换为一个Mock对象。当utils.py被导入时，它会从mod1.mod2中获取到这个Mock对象，并将其赋值给utils.py内部的CONST变量。
总结与注意事项
- 理解Python导入机制是关键： 当你使用from module import name时，name的值会被复制到当前模块的命名空间中。此后，对源模块中name的修改不会影响到已导入的副本。
- “在哪里被使用，就在哪里打补丁”原则： 这是解决这类问题的黄金法则。如果你想模拟一个变量，就应该在它被实际引用的那个模块或对象中进行打补丁。
- 方案一（在常量被使用的模块中打补丁）通常更清晰和推荐。 它直接修改了目标模块的内部状态，意图明确。
- 方案二（延迟导入）在某些复杂场景下可能有用， 例如，当一个模块的导入本身就有副作用，或者你希望在导入前就设置好所有依赖。但它会使测试代码看起来不那么直观，因为它改变了通常的模块导入方式。
在进行Python单元测试时，务必深入理解mock和patch的工作原理以及Python的模块和命名空间机制，这将帮助你避免常见的陷阱，并编写出健壮、有效的测试代码。
