本文讲解在单元测试中如何避免重复覆盖、同时确保代码健壮性：针对调用同一私有方法（如 `dosharedlogic`）的多个公有方法（如 `getmodels()` 和 `getmodel()`），应按职责分离测试边界——各自验证其核心行为（单查 vs 批量获取），而将共用逻辑的深度验证聚焦于一个明确入口，辅以文档约束与轻量防护。
在面向对象设计中，将重复逻辑抽取为私有方法（如 doSharedLogic(Model)）是良好实践；但在单元测试层面，直接对私有方法进行测试既不可行（受限于访问权限），也不符合测试分层原则。正确的策略是：以公有 API 为测试边界，按“行为职责”而非“实现路径”设计测试用例。
✅ 推荐测试策略：职责驱动 + 单点深测 + 文档防护
1. getModel(int id)：专注单实体生命周期
测试重点应覆盖：
- 正常场景（存在对应 ID 的模型）
- 边界/异常场景（ID 不存在、ID 为负数、空数据源等）
- 结果完整性验证：确认返回的 Model 经 doSharedLogic() 处理后状态正确（如字段被赋值、状态被标记、关联关系被初始化等）
@Test
void getModel_shouldApplySharedLogicAndReturnValidModel() {
// Given
when(repository.findById(1)).thenReturn(Optional.of(new Model(1, "original")));
// When
Model result = a.getModel(1);
// Then
assertNotNull(result);
assertEquals("processed", result.getStatus()); // 假设 doSharedLogic 设置了 status
assertTrue(result.isProcessed());
}2. getModels()：专注集合行为与流程控制
测试重点应覆盖：
- 返回非空列表（含单元素、多元素场景）
- 返回空列表（无数据时）
- 不重复验证 doSharedLogic 的细节，但需确保其被正确调用（可通过行为验证或间接断言）
@Test
void getModels_shouldInvokeDoSharedLogicForEachModel() {
// Given
List<Model> rawModels = Arrays.asList(
new Model(1, "A"),
new Model(2, "B")
);
when(repository.findAll()).thenReturn(rawModels);
// When
List<Model> results = a.getModels();
// Then
assertEquals(2, results.size());
// 间接验证：每个 model 的 shared logic 效果已体现在字段上
assertTrue(results.stream().allMatch(m -> "processed".equals(m.getStatus())));
}? 关键洞察：getModels() 的核心价值不在于“是否调用了 doSharedLogic”，而在于“是否对 每一个 获取到的模型都应用了该逻辑”。因此，测试应关注 最终状态一致性，而非调用次数——这比 Mockito 的 verify(..., times(n)) 更稳定、更贴近业务契约。
3. 防御性设计：让重构更安全
为防止未来开发者无意绕过共享逻辑（例如重写 getModels() 为直连数据库而跳过 doSharedLogic），建议：
- 在 getModels() 方法上方添加清晰注释：
/** * IMPORTANT: This method relies on {@link #getModel(int)} to ensure consistent * post-processing via {@link #doSharedLogic(Model)}. Do not bypass it without * updating corresponding tests and verifying all shared logic is preserved. */ public List<Model> getModels() { ... } - （可选）在 getModels() 测试中加入轻量断言，验证其 确实依赖 getModel() 或共享逻辑的输出特征（如统一字段值），形成“契约快照”。
❌ 不推荐的做法
- ✖️ 为 doSharedLogic 单独编写测试（无法直接访问私有方法；若强行反射测试，破坏封装且维护成本高）
- ✖️ 在两个公有方法的测试中完全复制相同的 doSharedLogic 行为断言（导致测试冗余、修复一处逻辑需同步改多处测试）
- ✖️ 过度使用 verify(mock, times(n)) 断言私有方法调用（耦合实现细节，使测试脆弱）
总结
单元测试的目标不是“覆盖每一行代码”，而是“守护每一个可观察的行为契约”。对共享私有逻辑，应选择一个主入口（如 getModel）承担深度逻辑验证职责，其他调用方（如 getModels）则聚焦自身差异化行为，并通过设计文档与间接状态断言构筑防御。这样既消除重复、提升可维护性，又保障了系统整体的可靠性。
