条件冗余虽不报错，但会降低可读性并掩盖缺陷；需通过分支覆盖暴露逻辑矛盾，结合jacoco条件覆盖率与参数化测试验证并定位冗余判断。
条件冗余本身不会直接报错，但会让代码逻辑变重、可读性下降，还可能掩盖真实缺陷。单元测试不是用来“发现冗余”的工具，而是通过**覆盖所有分支路径后暴露逻辑矛盾**，从而反向提示你：这里可能写多了。
用分支覆盖暴露隐藏的冗余判断
比如这段看似合理的校验：
public String getStatus(int score) {
if (score 0 && score = 60 && score
<p>表面看每个 if 都有作用，但第三行 <code>score > 0 && score 中的 <code>score > 0</code> 是冗余的——因为前两行已排除 ≤0 的所有情况。这种冗余不会让测试失败，但当你写全分支用例时会察觉异常：</code></p>
- 测
score = -1→ 进第一个 if（抛异常） - 测
score = 0→ 进第二个 if（返回“缺考”） - 测
score = 59→ 进第三个 if - 测
score = 60→ 进第四个 if
你会发现：第三个 if 的 score > 0 条件从未被“证伪”过——没有一个用例能让它为 false 却仍进入该分支。这就是分支覆盖报告里“部分条件未触发”的信号，提示你检查逻辑是否重复。
借助 JaCoCo 的“条件覆盖率”定位冗余
JaCoCo 支持条件覆盖率（Condition Coverage），它会统计每个布尔子表达式 true/false 是否都被执行过。对 score > 0 && score ，JaCoCo 会拆成两个条件：
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
-
score > 0：是否试过 true 和 false？ score ：是否试过 true 和 false？
如果报告中显示 score > 0 的 false 分支从未执行（即没构造过 ≤0 但又走到这里的输入），而代码上下文已确保 score 不可能 ≤0，那这个子条件就是冗余的。
参数化测试 + 断言组合验证逻辑一致性
用 JUnit 5 的 @ParameterizedTest 覆盖边界值，并断言输出唯一性：
@ParameterizedTest
@CsvSource({
"-1, IllegalArgumentException",
"0, 缺考",
"59, 弱",
"60, 合格",
"89, 合格",
"90, 优秀"
})
void testStatusCoverage(int score, String expected) {
if ("IllegalArgumentException".equals(expected)) {
assertThrows(IllegalArgumentException.class, () -> getStatus(score));
} else {
assertEquals(expected, getStatus(score));
}
}
一旦你删掉冗余条件，测试仍全部通过，且 JaCoCo 条件覆盖率不降反升（因为少了不可达分支），就基本确认它是安全冗余。
警惕“看似必要”的防御性判断
常见冗余模式包括：
- 在非空集合上调用
list != null && !list.isEmpty()，但上游已保证 list 不为 null - 对已校验过的参数再次做范围检查，如先有
Objects.requireNonNull(name)，后面又写if (name.length() == 0) - 多个 if 并列判断同一变量，且区间有重叠或遗漏间隙（如
、<code>>=60 && 、<code>>=80）
这类问题单靠人眼难识别，但只要坚持每个判断都配齐 true/false 用例，并配合 JaCoCo 条件覆盖率报告交叉比对，就能系统性揪出。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
