私有方法可以测试但不应直接mock，应优先通过公有接口验证行为；复杂逻辑可提取为模块函数或添加测试钩子；mock应针对外部依赖而非私有方法本身。
私有方法真的不能直接测试吗
Python 的私有方法（以 _ 或 __ 开头）没有真正的访问限制，只是约定和名称改写（name mangling）。__method 会被改写为 _ClassName__method，所以直接调用是可行的，但不推荐——它破坏封装，且一旦类名变更或 Python 版本升级导致 mangling 规则变化，测试就容易脆。
为什么不该 mock 私有方法本身
mock 的核心价值是隔离依赖、控制副作用，而不是绕过设计意图。对私有方法单独 mock 通常意味着：你正在测试实现细节而非行为，或者该方法本不该是私有的。
- mock
_helper后断言它被调用一次，不如验证公有方法process_data的输出是否符合预期 - 如果私有方法含 I/O、网络、时间等不可控逻辑，应把它提取为可注入的依赖（如传入
clock或http_client），再 mock 那个依赖 - 强行 mock
_ClassName__private_method会让测试代码变得难读且易碎
真正需要测试私有逻辑时的实操路径
当私有方法逻辑复杂、分支多、又确实无法通过公有接口全覆盖（比如中间状态需断言），可考虑以下方式，按优先级排序：
- 把私有方法改成模块级函数（无 self、无状态），在测试中直接导入并调用
from mymodule import _parse_config - 在类内部加一个受控的“测试钩子”：例如构造时传入
test_mode=True，触发一个公开的debug_run_private_step方法，仅用于测试 - 极少数情况才直接调用 mangling 后的名字：
obj._MyClass__validate_input()，但必须加注释说明原因，并用getattr(obj, "_MyClass__validate_input")替代硬编码字符串，避免拼错
mock 应该用在哪儿：替代它的协作对象
私有方法常调用外部资源，这才是 mock 的主战场。例如 _fetch_from_api 调用了 requests.get，你应该 mock requests.get，而不是 mock _fetch_from_api 本身。
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
立即学习“Python免费学习笔记（深入）”；
from unittest.mock import patch
import pytest
<p>def test_public_method_handles_api_failure():
with patch("mymodule.requests.get") as mock_get:
mock_get.side_effect = ConnectionError("timeout")
result = MyService().run() # 内部调用 _fetch_from_api
assert result == "fallback"</p>这样既保持了测试的黑盒性，又覆盖了私有方法中的关键错误路径。记住：mock 的目标永远是「不可控的边界」，不是「不想写的公有接口」。
最常被忽略的一点是：私有方法测试覆盖率高，往往说明公有接口设计得不够内聚——先审视接口职责，比急着 mock 更重要。
