本文深入探讨了在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_functionimport 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。
商汤商量
商汤科技研发的AI对话工具，商量商量，都能解决。
36 查看详情 
原因分析：
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.pyfrom 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的模块和命名空间机制，这将帮助你避免常见的陷阱，并编写出健壮、有效的测试代码。
以上就是Python中常量Mocking的陷阱与解决方案的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/584352.html
微信扫一扫 
支付宝扫一扫 
