本文探讨在存在共享私有逻辑（如 `dosharedlogic()`）时，如何合理设计 `getmodels()` 和 `getmodel()` 的单元测试：聚焦各自职责边界，避免逻辑重复验证，同时通过结构约束与文档化保障协作一致性。
在面向对象设计中，将共用行为提取为私有方法（如 doSharedLogic(Model)）是良好实践，但随之而来的是单元测试策略的挑战：若对每个调用方都完整覆盖共享逻辑的所有分支，会导致测试冗余、维护成本陡增；若仅测一处，又可能因后续重构（如 getModels() 意外绕过 doSharedLogic()）引入隐蔽缺陷。
核心原则：按契约测试，而非按实现测试
每个 public 方法应被视作一个独立契约（contract）——测试其输入/输出行为、边界条件与副作用，而非内部调用路径。据此拆分关注点：
-
✅ getModel(int id)：专注「单模型获取」语义
- 测试场景包括：正常 ID 返回非空模型、无效 ID 抛出异常或返回 null（依设计而定）、数据库为空时的行为；
- 若 doSharedLogic() 对模型执行关键转换（如字段标准化、状态初始化），此处需断言转换后的模型状态（例如 model.getStatus() == READY）；
- 不需 覆盖 doSharedLogic() 所有参数组合，只需验证该方法在「单模型上下文」中产生的正确终态。
-
✅ getModels()：专注「多模型集合行为」
- 测试场景包括：返回空列表、单元素列表、多元素列表、大数据量性能（可选）；
- 关键策略：隔离验证「集合组装逻辑」，不重复验证模型转换。可通过 Mockito 等框架 mock doSharedLogic() 的副作用（或使用 Spy + verify），确保它被调用，但不必断言其内部细节：
@Test
void getModels_callsDoSharedLogicForEachModel() {
// Given
Model model1 = new Model(1);
Model model2 = new Model(2);
List rawModels = Arrays.asList(model1, model2);
// When
List result = a.getModels(); // 假设 A 已被 Spy
// Then
verify(a, times(2)).doSharedLogic(any(Model.class)); // 确保每个模型都被处理
assertThat(result).hasSize(2);
} - ❌ 避免：在两个测试类中分别编写完全相同的 doSharedLogic() 输入-输出校验用例（如“传入 null model 应抛 NPE”、“传入 dirty model 应清理字段”）。
防御性保障：用代码即文档强化协作契约
为防止未来重构破坏调用关系，在 getModels() 方法内添加清晰注释，并在 doSharedLogic() 上添加 Javadoc 强调其契约义务：
/**
* Returns all models. Each model is processed via {@link #doSharedLogic(Model)}
* — this call is essential for data consistency. Do NOT remove or bypass it.
*/
public List getModels() { ... }
/**
* Applies mandatory post-retrieval transformations to ensure model validity.
* Called by {@link #getModel(int)} and {@link #getModels()}.
* @throws IllegalArgumentException if model is null
*/
private void doSharedLogic(Model model) { ... } 进阶建议：当共享逻辑极其复杂时
若 doSharedLogic() 自身逻辑厚重（如含多分支、外部依赖、状态变更），可将其抽取为包级可见的 package-private 方法，单独编写集成测试或行为驱动测试（BDD），使其成为可复用、可验证的“微契约”。此时 getModel() 和 getModels() 的测试只需保证调用发生，而非重复验证逻辑本身。
总结：单元测试的价值在于守护接口契约，而非镜像实现细节。通过职责分离测试、精准验证终态、显式文档约束，既能消除冗余，又能构建健壮、可演进的测试体系。
