Jacoco 显示分支未覆盖，通常是因为缺少触发所有条件分支（尤其是 else if 链中每个条件为 true 和 false 组合）的测试用例；添加负数输入可覆盖隐式 else 分支，从而满足完整分支覆盖率要求。
jacoco 显示分支未覆盖，通常是因为缺少触发所有条件分支（尤其是 `else if` 链中每个条件为 `true` 和 `false` 组合）的测试用例；添加负数输入可覆盖隐式 `else` 分支，从而满足完整分支覆盖率要求。
在使用 JaCoCo 进行分支覆盖率（Branch Coverage）分析时，if-else if-else 链中的每一对“条件判断”会被视为一个分支点（branch point），而每个 else if 实际对应两个分支：该条件为 true 的路径，以及为 false 但需继续向下判断的路径。JaCoCo 要求每个分支至少被执行一次才算“覆盖”。
观察原代码中的条件链：
if (roundedKms >= 0 && roundedKms = 11 && roundedKms = 21 && roundedKms = 31 && roundedKms = 41 && roundedKms = 51) { ... }
⚠️ 关键遗漏：没有测试 roundedKms 的情况！
由于 miles 是 double 类型且未经校验，传入负数（如 -1.0）会使 kilometers = -1.60934，进而 roundedKms = (int)Math.floor(-1.60934) = -2 —— 此值不满足任何 if 或 else if 条件，最终落入隐式 else 分支（即整个 if-else if 链之后的逻辑，此处为无操作，但 JaCoCo 仍将其计为一个未覆盖分支）。
因此，尽管你提供了 0, 1, 15, 25... 等多个正数用例，覆盖了前 5–6 个 else if 的 true 分支，但：
- 所有
else if的false路径（尤其首个if为false后进入后续判断的跳转）未被完整追踪； - 最关键的是，没有任何用例使整个条件链全部失败 → 隐式
else分支始终未执行 → JaCoCo 报告“1/4 branches not covered”（实际是多个分支点中至少一个缺失false路径）。
✅ 正确解法：显式补充边界外的反例
只需在 @ValueSource 中加入一个负数（如 -1），即可触发 roundedKms ，让控制流穿过全部 <code>if/else if 判断并最终“落空”，从而覆盖最后一个隐式分支：
@ParameterizedTest
@ValueSource(doubles = {
-1.0, // ✅ 触发全部条件为 false → 覆盖隐式 else 分支
0.0, // → roundedKms = 0 → 覆盖第 1 个 if
6.2, // → ~10.0 → still in [0,10]
12.5, // → ~20.1 → triggers 2nd else if ([11,20])
25.0, // → ~40.2 → 3rd branch ([21,30])
35.0, // → ~56.3 → 6th branch (>=51)
45.0 // → ~72.4 → also >=51 (redundant but harmless)
})
public void testMilesToKilometers(double miles) {
String url = String.format("/miles-to-kilometers?value=%.2f", miles); // ⚠️ 注意：原 URL 拼写有误，应为 ?value=...
given()
.when().get(url)
.then()
.statusCode(200)
.body(containsString("Kilometers: "))
.body(containsString(getExpectedMessageForMiles(miles)));
}
? 补充建议：
-
修复测试 URL 拼写错误：原代码中
"/miles-to-kilometers=%.2f"应为"/miles-to-kilometers?value=%.2f"，否则参数无法传递，导致miles使用默认值0.0，进一步削弱覆盖率真实性。 -
同步修正业务逻辑一致性：注意
getExpectedMessageForMiles()中第 5 个分支返回"unbelievable"，而主逻辑中对应位置是" is below 50"；第 6 个分支测试返回" is below 50"，但主逻辑是" more than 50"—— 这会导致断言失败，务必保持两侧逻辑严格一致。 -
推荐增强健壮性：对负数输入，建议在 API 中明确处理（如抛出
400 Bad Request），而非静默返回空消息，这既提升 API 质量，也使分支意图更清晰，便于测试设计。
通过一个精心选择的负值用例，即可低成本、高确定性地补全 JaCoCo 分支覆盖率，这是单元测试中“边界值分析（Boundary Value Analysis）”的经典实践。
