不该直接测试私有方法，因其是实现细节而非接口契约；应通过公有接口间接覆盖，或提取为独立可测组件。
不需要，私有方法本身就不该被直接测试；强行测试往往暴露设计问题，而不是测试需求本身。
为什么不该直接测私有方法
私有方法是实现细节，不是接口契约。测试它等于把测试绑死在当前实现上，稍一重构（比如拆分、内联、重命名）就会让测试失败，但行为可能完全没变。
常见错误现象：test_private_helper_returns_correct_value 在重构 process_data 时频繁报错，而对外行为 calculate_result() 依然正确——这说明测试在干扰开发，而非保障质量。
- 私有方法无法被单元测试框架（如 Google Test、Catch2）直接访问，常靠友元类、
protected提升、或宏 hack（如#define private public）绕过，这些都会污染生产代码或构建逻辑 - 测试私有方法容易掩盖真正的协作缺陷：比如多个私有方法之间耦合过紧，但测试只覆盖单点，漏掉组合路径
- C++ 没有反射，也没有像 Java 的
Method.setAccessible(true)，硬测成本高且不可移植
更合理的替代方案：通过公有接口间接验证
私有方法存在的意义，是支撑某个公有方法的正确输出或状态变更。只要覆盖公有方法的输入边界、异常路径和副作用，私有逻辑自然被覆盖。
立即学习“C++免费学习笔记（深入）”；
使用场景举例：一个 Parser 类含私有 parse_number() 和 skip_whitespace()，公有 parse(std::string_view) 是唯一入口。
- 为
parse()写测试：输入" 42 "→ 期望返回42；输入"abc"→ 期望抛std::invalid_argument - 若发现某条路径没被覆盖（比如
skip_whitespace()在连续制表符下行为异常），应补全parse()的测试用例，而不是去“单独测”那个私有函数 - 必要时可加
[[nodiscard]]或断言（assert）在私有方法内部，辅助调试，但不作为测试依据
如果真有逻辑必须隔离验证：考虑提取为独立类或命名空间函数
当一段私有逻辑复杂、复用性强、或需要独立验证（比如加密计算、数值积分），它其实已经超出“辅助实现”的范畴，属于有明确职责的组件。
这时重构不是为了方便测试，而是为了职责清晰：
- 将逻辑提取为
namespace detail { int compute_checksum(const std::vector<uint8_t>&); }</uint8_t>—— 无状态、无副作用，可直接测试detail::compute_checksum - 或封装为轻量级工具类（如
ChecksumCalculator），保持Parser简洁，且新类天然支持构造+调用+断言 - 避免提取后仍藏在原类内部（如
private class Helper）——这没解决可见性问题，只是换了个地方藏私有
真正难处理的从来不是“怎么测私有方法”，而是识别出哪些私有方法其实不该存在：它们要么太长（该拆），要么承担了本该由其他类负责的职责（该移），要么只是临时胶水代码（该删）。测试只是照镜子，照出的是设计，不是测试策略本身。
