本文深入探讨了在使用`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 CONSTdef mod_function(): print(CONST)
mod1/tests/test_utils.py:尝试使用mocker.patch来模拟CONST的值。
from mod1.mod2.utils import mod_functionimport pytest_mock # 仅为类型提示，实际使用pytest的mocker fixturedef 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，所以我们应该直接模拟这个引用。
商汤商量
商汤科技研发的AI对话工具，商量商量，都能解决。
36 查看详情 
修改后的test_utils.py:
from mod1.mod2.utils import mod_functionimport pytest_mockdef 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_mockdef 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之后)：
优点：如果目标模块的初始化逻辑依赖于被模拟的常量，或者有多个函数都依赖于同一个源模块的常量，这种方法可以一次性解决。适用场景：当测试需要确保模块加载时就获取到模拟值，或者需要模拟整个模块的加载行为时。
在实际开发中，通常推荐使用第一种方法，即直接模拟被测试模块中常量的本地引用，因为它更符合“就近原则”，且通常更容易理解和维护。然而，第二种方法在某些复杂场景下也提供了有效的替代方案。选择哪种方法取决于具体的测试需求和代码结构。
以上就是Pytest Mocker实战：理解并正确模拟导入的常量的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/584002.html
微信扫一扫 
支付宝扫一扫 
