测试私有成员应优先用友元精准授权，如friend class DataProcessorTest；其次可提取纯逻辑为独立函数并依赖注入，兼顾封装性与可测性。
测试需要访问私有成员，不等于必须把它们改成 public。硬开接口会破坏封装边界，后续维护成本远高于写几个测试桩。
用友元（friend）精准授权测试类
只让特定测试类访问私有成员，不暴露给其他任何代码。这是最常用也最克制的做法。
-
friend声明写在类内部，作用域极小，不影响类的封装性 - 测试类名需完整写出（包括命名空间），避免意外匹配
- 不能对模板类的特化做泛型
friend class TestSuite<T>，必须显式声明每个特化
class DataProcessor {
private:
int internal_state_;
void validate_state() const { /* ... */ }
<p>// 只授权给这个测试类
friend class DataProcessorTest;
};
提取逻辑到独立函数 + 依赖注入
把私有方法中可测试的核心逻辑抽成自由函数或静态成员函数，测试时直接调用它，而无需碰原类的私有区。
- 被抽离的函数应无副作用、纯计算、参数明确
- 原私有方法变成薄包装层，只负责协调和状态管理
- 这种拆分天然支持单元测试，也提升了复用性
// 可测试的纯函数
bool is_valid_input(int x) {
return x > 0 && x < 100;
}
<p>class DataProcessor {
private:
void process_impl(int input) {
if (!is_valid_input(input)) { /<em> ... </em>/ }
}
};
通过公共接口覆盖私有行为路径
多数私有方法服务于某个公共行为，只要该行为的输入/输出可观察，就完全可以通过公共接口驱动并断言结果。
立即学习“C++免费学习笔记（深入）”；
- 测试关注“做了什么”，而不是“怎么做的”
- 例如私有
cache_result()是否生效，可通过重复调用同一get_value()并测耗时或 DB 查询次数来验证 - 避免为测试加“后门接口”，比如
force_invalidate_cache()
GTest 中的 TEST_F 配合保护继承（慎用）
仅当类本身已将关键逻辑放在 protected 成员中，且你确认该设计合理时，才考虑让测试类继承它。这不是补救方案，而是设计选择。
- 继承
protected成员的前提是：这些成员本就是有意暴露给子类的扩展点 - 若原类所有成员都是
private，强行改为protected仅为测试，属于倒置职责 - 比起改访问修饰符，优先检查是否该把逻辑上收为
static或下放为策略对象
真正难测的私有方法，往往提示设计问题：它可能承担了太多职责，或与外部依赖耦合过紧。比起绕过封装，更值得花时间重构它的边界。
