分支覆盖率提升

要解决什么问题

团队里常见两种极端：要么为了「有测试」堆 assertNotNull，覆盖率数字好看却测不到分支行为；要么为了好测去改生产代码可见性，把 private 改成 public 或先重构再补测。boosting-coverage 针对的是在不动源码的前提下，用最少用例把条件分支、循环边界、异常路径真正跑过，并用覆盖率工具核对缺口。

技能如何工作

流程可以概括为四步：

1. 摸底与分支映射：通读源码，按分支密度优先排序；跳过 POJO、纯委托、空类。对每个方法列出 if/else、三元、&&/||、早返回、switch（含 default）、循环（0/1/多次）、try/catch 等路径。
2. 规划最小测试集：按同一条执行路径合并分支——例如用 null、-1、1 三个输入激活不同分支组合，而不是为每个分支各写一条重复路径的用例。
3. 编写测试：只 mock I/O 与外部系统；通过 public 入口覆盖 private 逻辑；参数化相同逻辑不同输入；断言该分支产生的具体结果，而非仅非空。
4. 验证与裁剪：对照覆盖率报告补红/黄行；逐条问「删掉这条测试，其它用例是否仍覆盖这些分支？」——若是则删除冗余。

技能还给出常见场景对照（void 副作用、assertThrows、嵌套 if、enum switch）以及必须停止的红线：改源码、过度 mock、无分支意识的乱写测试、不跑工具就宣称覆盖、跳过难达分支而不标注死代码。

适用边界

它指导的是分支导向的单元/集成测试设计，不是替代 CI 配置或选型覆盖率插件。若某分支在现有 API 下确实不可达，应文档化而非强行「测到」；反射仅作最后手段。