应通过公共方法的可观察行为测试私有逻辑，优先构造输入、调用公共方法并断言输出；复杂私有方法应提取为独立类以提升可测性与复用性；反射仅作最后手段且需严格管控；避免使用powermock等侵入式mock工具。
不直接测试私有方法，而是验证它带来的可观察行为。
优先通过公共方法输出断言私有逻辑
私有方法是实现细节，不是契约的一部分。只要它影响了公共方法的返回值、状态变更或外部交互，就完全可以通过检查这些可观测结果来覆盖其逻辑。比如一个 transform() 方法负责填充 extras 字段，最终体现在 CancelOrder.premiumSummary.extras 中——那测试只需断言这个字段的值是否符合预期，无需碰私有方法本身。
- 构造合适的输入，触发私有方法执行
- 调用公共方法（如 generateCancelOrder()）
- 检查返回对象中与私有逻辑相关的具体字段或嵌套结构
- 必要时 mock 依赖（如静态计算方法），控制其返回值以验证不同分支
复杂私有逻辑应考虑重构而非硬测
如果一个私有方法长达几十行、含多层条件或独立算法，说明它已超出“辅助功能”范畴。这时强行用反射去测，不如把它提取成独立的、有明确职责的类（例如 VoluntaryExtrasCalculator），并赋予公共接口。这样既提升可读性与复用性，又天然支持单元测试。
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 提取后，原类只保留协调逻辑，测试更轻量
- 新类可被多个模块复用，避免重复实现
- 测试目标清晰：输入 → 输出，无需绕过访问控制
反射调用仅作为最后手段，且需严格管控
仅在极少数无法重构、又必须确认私有方法执行路径的场景下（如遗留系统关键校验），才使用反射。操作上必须显式调用 setAccessible(true)，并确保测试环境允许该行为（JDK 9+ 模块系统需额外配置）。但要注意：这类测试脆弱、难维护，且一旦私有方法签名变动就会立即失败。
- 使用 getDeclaredMethod() 获取方法对象
- 调用 method.setAccessible(true)
- 用 invoke() 执行，并捕获可能的异常
- 在测试类顶部加注释说明为何必须走此路径
避免用 PowerMock 或旧版 Mockito 强行 mock 私有方法
PowerMock 虽能 mock 私有方法，但代价是侵入类加载器、破坏测试隔离性，且与现代 JDK 兼容性差；Mockito 5.x 的 inline 支持也仅面向静态方法，对私有方法无原生支持。这些工具容易让团队陷入“能测≠该测”的误区，掩盖设计问题。
- 引入 PowerMock 会显著拖慢测试执行速度
- 测试代码与实现细节强耦合，重构成本翻倍
- 多数情况下，真正需要的是更清晰的职责划分，而不是更强的 mocking 能力
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
