提高Java单元测试覆盖率的关键是覆盖不同执行路径和边界状态；需用JaCoCo获取真实数据，关注行与分支覆盖率，结合参数化测试、Mock隔离依赖及异常场景验证。
提高 Java 单元测试的代码覆盖率，关键不是堆砌测试数量，而是让每个测试真正触达不同执行路径和边界状态。覆盖率高不等于质量好，但低覆盖率一定意味着风险区域没被验证。
用 JaCoCo 获取真实覆盖数据
没有测量就谈不上优化。JaCoCo 是当前最主流、集成最顺畅的 Java 覆盖率工具：
- 在 Maven 的 pom.xml 中添加插件，启用
prepare-agent目标，确保测试运行时自动注入探针 - 执行
mvn clean test jacoco:report后，会在target/site/jacoco/下生成 HTML 报告 - 重点看“行覆盖率（Line Coverage）”和“分支覆盖率（Branch Coverage）”——后者更能暴露 if/else、switch 等逻辑盲区
- 把报告接入 SonarQube，可长期追踪趋势，并设置质量门禁（如分支覆盖率低于 70% 不允许合入）
覆盖所有执行路径，不只是“能跑通”
一个方法里有 if-else-if-else，只测一个分支只算覆盖了 1/3 的决策点。必须显式构造每种输入：
- 对
scoreLevel(int score)这类方法，至少要测：负数（异常）、0（边界）、59（弱）、60（差）、79（中）、80（良）、90（优）、101（超限） - 用 JUnit 5 的
@ParameterizedTest+@ValueSource或@CsvSource避免重复代码 - 不要忽略空集合、null 参数、超长字符串等易被忽略的边界值
合理使用 Mock，隔离依赖才能测得准
外部依赖（数据库、HTTP 调用、时间等）会干扰单元测试的纯粹性和稳定性：
立即学习“Java免费学习笔记（深入）”；
- 用 Mockito 模拟服务层返回，比如让
userService.findById(1L)返回预设对象，避免真实查库 - 对静态方法或 final 类，可用 Mockito 4+ 的 inline mock 支持，或改用 PowerMock（谨慎评估维护成本）
- 时间相关逻辑统一用
Clock注入，测试时固定为某一时点，避免因系统时间漂移导致断言失败
让异常场景成为测试标配
很多 bug 发生在异常流里，但开发者常只关注 happy path：
- 对抛出异常的方法，用
@Test(expected = IllegalArgumentException.class)或assertThrows()显式验证 - 检查异常消息是否符合预期（比如是否包含关键字段名），防止错误提示模糊难排查
- 模拟底层服务抛异常，验证上层是否做了兜底（如返回默认值、记录日志、触发降级）
