本文探讨在单元测试中如何避免重复代码，同时确保调用同一私有逻辑（如 dosharedlogic()）的多个公有方法（如 getmodels() 和 getmodel()）各自行为的完整性与可靠性。核心原则是：按职责分层验证——公有方法测契约与边界，私有逻辑测行为本质。
在面向对象设计中，将共用逻辑抽取为私有方法（如 doSharedLogic(Model)）是良好的重构实践，但随之而来的是单元测试策略的选择难题：是否要在每个调用它的公有方法测试中重复覆盖相同的逻辑分支？答案是否定的——重复测试不仅违背 DRY 原则，更会降低可维护性、掩盖真实缺陷焦点。
正确的做法是实施分层验证（Layered Verification）：
✅ getModel(int id) 的测试重点：
- 验证单模型获取的语义正确性：ID 存在、不存在、非法值（如负数/零）等边界场景；
- 验证其返回值是否符合预期（如非空、字段状态正确），但不重复校验 doSharedLogic() 的内部变换细节；
- 若 doSharedLogic() 涉及副作用（如修改模型状态），可通过 Mockito 或 verify() 检查该方法是否被调用（间接验证），而非断言最终状态——因为状态逻辑应由 doSharedLogic() 的专属测试覆盖。
✅ getModels() 的测试重点：
验证集合级行为：空列表、单元素、多元素、排序/去重等业务规则（如有）；
若其实现依赖 getModel()（例如循环调用），应通过 @Mock 或 @Spy 对 getModel() 进行受控模拟，聚焦于“组合逻辑”本身，而非重新走一遍模型转换流程；
-
示例（JUnit 5 + Mockito）：
@Test void getModels_callsGetModelForEachId() { // 给定：模拟 getModel 返回预设模型 when(mockA.getModel(1)).thenReturn(new Model("A")); when(mockA.getModel(2)).thenReturn(new Model("B")); // 当：调用 getModels() Listresult = mockA.getModels(); // 假设其内部遍历 ID 列表并调用 getModel // 那么：验证调用次数与结果 verify(mockA, times(1)).getModel(1); verify(mockA, times(1)).getModel(2); assertThat(result).hasSize(2); }
✅ doSharedLogic(Model) 的专属测试（关键！）：
- 单独编写 doSharedLogicTest 类或方法，全面覆盖所有输入组合与异常路径（如 null 模型、字段为空、状态冲突等）；
- 使用真实对象（非 mock）执行该方法，直接断言模型字段变更、集合操作结果等；
- 此测试是“单一可信源”，确保共享逻辑的健壮性——只要它通过，所有调用方的行为基础就可靠。
? 重要注意事项：
- 禁止在 getModel() 和 getModels() 测试中复制 doSharedLogic() 的数据断言。这会导致：一处修复需同步改多处测试，极易遗漏，且模糊了各层职责；
- 若未来 getModels() 被重构为绕过 getModel()（如直连数据库），这不是测试能阻止的，而是设计契约与文档的责任：在 getModels() 方法注释中明确标注 “This method delegates to getModel() for per-item processing — modifying this dependency requires updating both implementation and related tests.”；
- 对于无法直接测试的私有方法（如 Java 中的 private），可考虑：① 将其提升为包级 default 方法（便于测试包内访问）；② 通过公有方法的可观测输出间接验证（推荐）；③ 使用反射（仅限极端场景，破坏封装性，不推荐）。
总结而言，高质量的单元测试不是追求“行覆盖”，而是追求“契约覆盖”与“风险覆盖”。让每个测试单元各司其职：公有 API 守住接口契约，私有逻辑守住行为本质——如此，代码可演进、测试可维护、质量可持续。
