应优先通过公有方法间接验证私有方法行为，其次考虑包级访问+同包测试，最后才用反射调用；判断标准包括封装核心业务规则、公有方法仅串联私有方法、代码难以安全重构。
先看要不要测：三个现实信号帮你判断
不是所有私有方法都该单独测。如果出现以下任一情况，说明值得考虑介入：
- 私有方法里封装了核心业务规则（比如保费计算、风控评分、状态转换逻辑）
- 公有方法只是简单串联多个私有方法，几乎不带分支或校验
- 当前代码无法安全重构（没测试覆盖、无文档、多人维护、上线压力大）
方案一：用反射调用私有方法（最常用）
这是最直接、无需改源码、兼容性好的方式。注意两点：设 setAccessible(true) 和正确处理异常。
示例：
@Test
void testPrivateCalculateDiscount() throws Exception {
OrderService service = new OrderService();
Method method = OrderService.class.getDeclaredMethod("calculateDiscount", BigDecimal.class, String.class);
method.setAccessible(true);
BigDecimal result = (BigDecimal) method.invoke(service, new BigDecimal("100"), "VIP");
assertEquals(new BigDecimal("90"), result);
}
⚠️ 注意：方法名或参数类型一变，测试就红；适合临时兜底，不适合长期维护的高稳定性项目。
立即学习“Java免费学习笔记（深入）”；
方案二：包级访问 + 同包测试（轻量且稳定）
把私有方法的访问修饰符从 private 改成默认（即不写任何修饰符），它就变成包级可见。然后在 test 目录下建一个同包路径的测试类，就能直接调用。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
例如源码在 com.example.order 包下，测试类也放在 src/test/java/com/example/order 路径即可。
优点是零反射、IDE友好、编译期检查强；缺点是略微放宽了封装——但仅限测试包可见，不影响生产调用。
方案三：通过公有方法间接验证（推荐优先尝试）
不碰私有方法本身，而是检查它产生的可观测结果：返回值字段、对象状态变化、抛出的异常、外部依赖的交互（如 mock 的 service 调用次数）。
例如私有方法 transformExtras() 负责填充 orderSummary.extras，那就断言最终返回的 CancelOrderResponse.premiumSummary.extras 是否符合预期。
这种方式让测试与实现解耦，重构时只要行为不变，测试就依然绿——这才是单元测试本意。
