条件冗余虽不报错，但会降低可读性并掩盖缺陷；需通过分支覆盖暴露逻辑矛盾，结合JaCoCo条件覆盖率与参数化测试验证并定位冗余判断。
条件冗余本身不会直接报错，但会让代码逻辑变重、可读性下降，还可能掩盖真实缺陷。单元测试不是用来“发现冗余”的工具，而是通过**覆盖所有分支路径后暴露逻辑矛盾**，从而反向提示你：这里可能写多了。
用分支覆盖暴露隐藏的冗余判断
比如这段看似合理的校验：
public String getStatus(int score) {
if (score < 0) throw new IllegalArgumentException("负分");
if (score == 0) return "缺考";
if (score > 0 && score < 60) return "弱";
if (score >= 60 && score < 90) return "合格";
return "优秀";
}
表面看每个 if 都有作用，但第三行 score > 0 && score 中的 <code>score > 0 是冗余的——因为前两行已排除 ≤0 的所有情况。这种冗余不会让测试失败，但当你写全分支用例时会察觉异常：
- 测
score = -1→ 进第一个 if（抛异常） - 测
score = 0→ 进第二个 if（返回“缺考”） - 测
score = 59→ 进第三个 if - 测
score = 60→ 进第四个 if
你会发现：第三个 if 的 score > 0 条件从未被“证伪”过——没有一个用例能让它为 false 却仍进入该分支。这就是分支覆盖报告里“部分条件未触发”的信号，提示你检查逻辑是否重复。
立即学习“Java免费学习笔记（深入）”；
借助 JaCoCo 的“条件覆盖率”定位冗余
JaCoCo 支持条件覆盖率（Condition Coverage），它会统计每个布尔子表达式 true/false 是否都被执行过。对 score > 0 && score ，JaCoCo 会拆成两个条件：
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
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 并列判断同一变量，且区间有重叠或遗漏间隙（如
<60、>=60 && <90、>=80）
这类问题单靠人眼难识别，但只要坚持每个判断都配齐 true/false 用例，并配合 JaCoCo 条件覆盖率报告交叉比对，就能系统性揪出。
