本文深入探讨了在使用`pytest-mock`模拟python中从其他模块导入的常量时常遇到的陷阱。通过分析python的导入机制，解释了为何直接对源模块常量进行`patch`可能无效，并提供了两种有效的解决方案：直接模拟使用常量的模块内部引用，或延迟导入相关函数直至常量已被模拟，确保测试的准确性。
在进行单元测试时，我们经常需要隔离被测试代码的外部依赖，其中就包括常量。pytest-mock提供了一个强大的mocker fixture，用于模拟（mock）各种对象。然而，当常量从另一个模块导入时，直接对其源模块进行patch操作可能无法达到预期效果。本文将深入分析这一现象，并提供两种可靠的解决方案。
场景重现：为何直接Patch无效？
考虑以下典型的Python项目结构：
mod1
├── mod2
│ ├── __init__.py
│ └── utils.py
└── tests
└── test_utils.py其中文件内容如下：
mod1/mod2/__init__.py: 定义了一个常量CONST。
CONST = -1
mod1/mod2/utils.py: 从mod1.mod2导入CONST并在函数中使用。
from mod1.mod2 import CONST
def mod_function():
print(CONST)mod1/tests/test_utils.py: 尝试使用mocker.patch来模拟CONST的值。
from mod1.mod2.utils import mod_function
import pytest_mock # 仅为类型提示，实际使用pytest的mocker fixture
def test_mod_function(mocker: pytest_mock.MockerFixture):
mock = mocker.patch("mod1.mod2.CONST")
mock.return_value = 1000
mod_function()当我们运行pytest -s ./mod1/tests时，期望看到输出1000，但实际输出却是-1。这表明对mod1.mod2.CONST的模拟操作并未生效。
Python导入机制详解：问题的根源
要理解为何上述模拟失败，关键在于掌握Python的from ... import ...语句的工作原理。
当mod1/mod2/utils.py执行from mod1.mod2 import CONST时，Python解释器会执行以下操作：
- 加载或查找mod1.mod2模块。
- 在mod1.mod2模块的命名空间中查找名为CONST的对象。
- 在mod1.mod2.utils模块的本地命名空间中创建一个新的名字CONST，并让它引用（指向）mod1.mod2模块中找到的那个对象（即整数-1）。
这意味着，mod1.mod2.utils模块内部的CONST现在是一个独立的引用，它指向了原始的-1。
当test_mod_function中执行mock = mocker.patch("mod1.mod2.CONST")时，它所做的实际上是将mod1.mod2模块对象的CONST属性设置为一个新的Mock对象。此时：
- mod1.mod2.CONST现在指向了一个Mock对象。
- 然而，mod1.mod2.utils模块内部的CONST仍然指向原始的整数-1。
因此，对mock.return_value的设置只会影响到通过mod1.mod2.CONST这个路径访问到的值，而不会影响到mod1.mod2.utils模块内部已经创建的CONST引用。这就是mod_function仍然打印-1的原因。
解决方案一：直接模拟目标模块中的常量引用
最直接有效的解决方案是模拟常量在被使用模块（即mod1.mod2.utils）内部的引用。因为mod_function实际使用的是mod1.mod2.utils命名空间中的CONST，所以我们应该直接模拟这个引用。
修改后的test_utils.py:
from mod1.mod2.utils import mod_function
import pytest_mock
def test_mod_function_patch_local(mocker: pytest_mock.MockerFixture):
# 直接模拟mod1.mod2.utils模块中的CONST引用
mock = mocker.patch("mod1.mod2.utils.CONST")
mock.return_value = 1000
mod_function() # 此时mod_function会使用被模拟的CONST通过mocker.patch("mod1.mod2.utils.CONST")，我们直接修改了mod1.mod2.utils模块命名空间中CONST所指向的对象。这样，当mod_function被调用时，它会访问到这个被模拟的Mock对象，从而输出1000。
解决方案二：延迟导入使用常量的函数
另一种方法是确保在mod1.mod2.CONST被模拟之后，再导入并使用依赖它的函数。这样，当mod1.mod2.utils模块被加载时，它会从已经打过补丁的mod1.mod2模块中导入CONST。
修改后的test_utils.py:
# from mod1.mod2.utils import mod_function # 移除此处导入
import pytest_mock
def test_mod_function_defer_import(mocker: pytest_mock.MockerFixture):
# 首先模拟mod1.mod2模块中的CONST
mock = mocker.patch("mod1.mod2.CONST")
mock.return_value = 1000
# 在常量已被模拟后，再导入mod_function
# 此时mod1.mod2.utils模块在加载时会获取到被模拟的CONST
from mod1.mod2.utils import mod_function
mod_function()在这个解决方案中，mocker.patch("mod1.mod2.CONST")在from mod1.mod2.utils import mod_function之前执行。当mod1.mod2.utils模块首次被导入时，它会查找mod1.mod2中的CONST。由于此时mod1.mod2.CONST已经被mocker替换为一个Mock对象，mod1.mod2.utils模块中的CONST引用就会指向这个Mock对象，从而达到模拟的目的。
总结与最佳实践
理解Python的导入机制是有效进行单元测试的关键。当处理从其他模块导入的常量时，我们不能仅仅模拟常量的原始定义位置，因为from ... import ...语句会创建本地引用。
-
直接模拟本地引用 (mocker.patch("module.submodule.utils.CONST"))：
- 优点：简单直接，明确指出要模拟的是哪个模块中的哪个引用。
- 适用场景：当常量已经被导入到目标模块中，且我们只关心该模块内部对常量的使用时。这通常是更推荐和直观的方法。
-
延迟导入 (from ... import ...在patch之后)：
- 优点：如果目标模块的初始化逻辑依赖于被模拟的常量，或者有多个函数都依赖于同一个源模块的常量，这种方法可以一次性解决。
- 适用场景：当测试需要确保模块加载时就获取到模拟值，或者需要模拟整个模块的加载行为时。
在实际开发中，通常推荐使用第一种方法，即直接模拟被测试模块中常量的本地引用，因为它更符合“就近原则”，且通常更容易理解和维护。然而，第二种方法在某些复杂场景下也提供了有效的替代方案。选择哪种方法取决于具体的测试需求和代码结构。
