私有方法不应直接测试，应通过公开接口间接验证或重构为可测函数；强行访问破坏封装、增加维护成本，且测试易因重构失效。
私有方法在 Python 中本就不该被直接测试，强行访问会破坏封装、增加维护成本。真正需要做的是：验证公开接口的行为，间接覆盖私有逻辑；或重构让私有逻辑可测——而不是绕过下划线约定。
为什么不能直接测试 _private_method？
Python 的单下划线前缀（如 _helper）是约定而非强制限制，但 pytest 运行时不会特殊对待它。问题通常不来自“访问失败”，而是：
- 测试用例依赖内部实现细节，一旦重构
_private_method，所有相关测试立刻失效 - pytest 发现测试函数名以
test_开头但位于非测试模块，可能跳过或报ImportError - 某些 IDE 或静态检查工具（如 pylint）会警告对
_private_method的直接调用
如何安全地触发私有逻辑？
让私有方法的输入/输出通过公开方法暴露出来，然后断言结果。例如：
class Calculator:
def add(self, a, b):
return self._do_math(a, b, "add")
<pre class="brush:php;toolbar:false;">def _do_math(self, x, y, op):
return x + y if op == "add" else x - y
立即学习“Python免费学习笔记（深入）”；
对应测试应写成：
def test_add_returns_sum():
calc = Calculator()
assert calc.add(2, 3) == 5 # 不碰 _do_math，但覆盖了它的执行路径
- 如果
_do_math有复杂分支，就补多个add/subtract测试用例，而不是直接调用_do_math - 若私有方法纯计算且无副作用，可考虑将其移出类、变成模块级函数，自然获得可测试性
实在要访问怎么办？别用 getattr，改用 obj._method_name
虽然不推荐，但若调试或临时验证必须调用，直接点号访问最简单，也最不容易出错：
# ✅ 可行（不推荐但有效）
result = calc._do_math(10, 4, "add")
<h1>❌ 避免 getattr(obj, "_do_math")() —— 容易拼错、IDE 不提示、类型检查失效</h1><h1>❌ 更糟：eval("calc._do_math(...)") —— 安全与可读性双崩</h1><p>立即学习“Python免费学习笔记（深入）”；
- Pytest 不会拦截
obj._method()调用，只要对象存在该属性，就能运行 - 注意：如果类用了
__slots__且没包含"_do_math"，或定义了__getattr__，才可能真正抛AttributeError - 这种写法会让 pytest 报告里显示为
test_xxx.py::test_something，但实际测试的是非公开契约
什么情况下该重构而不是硬测？
当出现以下任一信号，说明设计已偏离测试友好性：
- 多个测试用例都在重复调用同一个
_xxx方法 - 私有方法参数多、逻辑重，且无法通过公开 API 全路径触发
- 你发现自己在测试中 mock
_private_method—— 这等于在测 mock 行为，不是业务逻辑
这时更稳妥的做法是：把该私有方法拆成独立函数，放进 utils/ 或 helpers/ 模块，加类型注解和单元测试，再在类中 import 使用。Python 的“私有”本质是沟通信号，不是技术壁垒——别用反射对抗意图。
