怎么在Python pytest中模拟（Mock）私有方法或私有属性？

Python 的“私有”只是个约定，不是真正的限制。单下划线（_name）是提醒“别碰我”，双下划线（__name）触发名称改写（_ClassName__name），但你想访问照样能访问。pytest + unittest.mock 压根不区分公私——只要你拿到对象引用，就能打桩。很多人一上来就想 mock 私有方法，结果发现那方法根本没人调过，只是内部实现细节。测试的核心是验证公共接口行为，而不是盯着实现代码看。如果私有方法逻辑很重（比如发请求、读文件），更合理的做法是把它抽成独立函数或服务类，然后对那个可测试单元做 mock。非要 mock _helper() 的话，直接给实例方法赋值个 Mock 就行：type(instance)._helper = Mock(return_value=42)。对于双下划线的 __process()，patch 时要用改写后的名字 _ClassName__process。

私有方法在pytest中根本不需要Mock

Python没有真正的私有机制，所谓“私有”只是命名约定（_name）或弱封装（__name触发名称改写）。pytest + unittest.mock 本身不区分公私，只要能访问到对象，就能打桩。

一种常见的误区是试图用 patch 去 mock 一个根本没被外部调用的私有方法——它通常只是内部实现细节，测试应聚焦在公共接口行为上。

• 如果私有方法逻辑复杂、副作用明显（比如发HTTP请求、读文件），建议把它提取为独立函数或服务类，再对那个可测试单元做mock
• 若坚持要mock _helper()，直接 patch 实例方法即可：type(instance)._helper = Mock(return_value=42)
• 对双下划线方法如 __process()，实际属性名变成 _ClassName__process，patch时必须用改写后的名字

用patch.object安全地替换实例私有方法

相比全局 patch，patch.object 更精准，可以避免影响其他测试。关键在于传入目标实例和改写后的方法名（尤其是双下划线方法）。

def test_with_private_method_mock():
    obj = MyClass()
    # 对 _internal_calc 直接 patch
    with patch.object(obj, '_internal_calc', return_value=99):
        assert obj.public_api() == 99

# 对 __validate，需用名称改写后的形式
with patch.object(obj, '_MyClass__validate', return_value=True):
    assert obj.process() is True

• 不要 patch 类定义里的 __validate，而要 patch 实例上的 _MyClass__validate
• 使用 patch.object 而非 patch，避免误伤同名方法在其他实例上的行为
• 若私有方法被 @staticmethod 或 @classmethod 修饰，patch位置要相应调整到类对象上

Mock私有属性时别碰__dict__硬编码

私有属性如 self._cache 或 self.__data 直接赋值覆盖即可，没必要动 __dict__。强行操作 __dict__ 容易因名称改写失效，而且破坏代码可读性。

• 安全做法：obj._cache = {"key": "fake"}（单下划线）或 obj._MyClass__data = b"raw"（双下划线）
• 错误做法：obj.__dict__["_MyClass__data"] = ... —— 依赖内部结构，PyPy或未来CPython版本可能变化
• 如果私有属性是只读的（比如通过 @property 控制），应 mock 对应的 property 方法，而不是底层字段

为什么多数情况下不该Mock私有成员

需要 mock 私有方法或属性，往往暗示设计上有值得商榷的地方：要么职责过重，要么边界模糊。pytest 的真正价值在于验证可观测行为，而不是检查代码是怎么写的。

• 当测试被迫依赖私有实现，意味着重构时测试会频繁失败，这违背了“测试应当稳定反映需求”的原则
• 真正需要隔离的是外部依赖（数据库、网络、时间），而不是同类里的另一个方法
• 如果发现必须 mock 私有方法才能让测试通过，先停下来问自己：这个方法是否应该拆成独立可测试的单元？它的输入输出能否显式化？

名称改写、patch路径、实例绑定方式——这些细节确实容易弄错，但更关键的是：先确认你真的需要它。