对复杂业务工具类做单元测试，关键在于围绕契约行为设计用例：明确输入、输出、异常及边界处理；覆盖典型组合与临界值；断言行为而非实现；善用参数化测试提升效率。
对复杂的业务工具类做全面单元测试，关键不是“测全所有分支”，而是围绕它的契约行为设计用例：输入什么、输出什么、抛出什么异常、边界怎么处理。工具类通常无状态、无依赖、纯逻辑，这反而是单元测试最理想的对象。
明确工具类的职责边界
先通读方法签名和文档（或注释），确认它要解决什么问题。比如一个 DateRangeUtils 工具类，核心方法是 splitByMonth(LocalDate start, LocalDate end)，那它的契约就是：
– 输入合法日期区间 → 返回按自然月拆分的 List<localdaterange></localdaterange>
– 输入 start > end → 抛 IllegalArgumentException
– 输入 null → 抛 NullPointerException
这些就是你必须覆盖的测试场景，而不是盲目测“2025年2月1日到2026年3月15日”这种具体日期。
覆盖典型输入组合与边界值
按输入特征分组设计用例，避免遗漏关键逻辑分支：
- 正常区间：跨月（如 2025-01-15 → 2025-03-10）、同月（2025-05-03 → 2025-05-20）、跨年（2024-12-20 → 2025-01-05）
- 临界点：月初/月末（2025-06-01 → 2025-06-30）、闰年2月（2024-02-01 → 2024-02-29）、跨世纪（1999-12-31 → 2000-01-01）
- 异常输入：start=null、end=null、start=end、start.after(end)
用断言验证行为，不验证实现细节
工具类测试重点是“结果是否符合预期”，不是“内部怎么算的”。例如：
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
立即学习“Java免费学习笔记（深入）”；
- ✅ 正确写法：
assertThat(result).containsExactly(range1, range2); - ❌ 错误写法：
verify(privateHelperMethod).wasCalledWith(...);（工具类不该有私有可 mock 的逻辑）
如果工具类内部调用了其他静态方法（如 StringUtils.isBlank()），不用 mock —— 它们本身也应有独立测试；你只需确保最终输出正确。
善用参数化测试提升效率
JUnit 5 的 @ParameterizedTest 非常适合工具类批量验证。例如验证一个金额格式化工具：
- 输入
1234.567→ 期望"¥1,234.57" - 输入
-89.0→ 期望"-¥89.00" - 输入
0→ 期望"¥0.00"
把这些写成 CSV 或方法源，一条测试方法就能跑完全部，结构清晰、维护成本低。
