Jest 原生不支持“仅统计新增代码覆盖率”，但可通过结合 --onlyChanged、覆盖率报告分析、Git 差异比对及第三方工具（如 SonarCloud）实现近似目标。本文提供可落地的工程化方案，含脚本示例与集成建议。
jest 原生不支持“仅统计新增代码覆盖率”，但可通过结合 `--onlychanged`、覆盖率报告分析、git 差异比对及第三方工具（如 sonarcloud）实现近似目标。本文提供可落地的工程化方案，含脚本示例与集成建议。
Jest 本身的设计聚焦于文件/函数/行级覆盖率统计，而非“按代码变更上下文动态限定覆盖范围”。因此，即使使用 jest --onlyChanged --coverage，覆盖率报告仍基于整个被修改文件生成（如题中 newFn 所在的完整 .js 文件），无法自动剥离 oldFn 等历史代码——这正是用户期望获得“100% 新增代码覆盖率”的核心障碍。
不过，我们可以通过以下三种实用路径逼近目标：
✅ 方案一：基于 Git 差异 + 行号提取 + 覆盖率过滤（本地自动化）
利用 git diff 获取本次变更的行号范围，再解析 Jest 生成的 coverage/lcov.info 或 JSON 报告，仅统计被修改行的覆盖状态。以下为轻量级 Bash + Node.js 示例脚本逻辑：
# 1. 获取当前分支相对于主干的新增/修改行号（简化版，实际需适配 git diff 格式） git diff origin/main --unified=0 | \ grep "^[+@]" | \ grep -E '^\+[0-9]+|^@@.*\+[0-9]+' | \ sed -E 's/^\+([0-9]+).*/\1/; s/.*\+([0-9]+)(,|$)/\1/' | \ sort -n | uniq > changed-lines.txt # 2. 运行 Jest 并输出详细覆盖率（JSON 格式便于解析） jest --coverage --coverageReporters=json --json --outputFile=coverage/coverage-final.json # 3. 使用自定义脚本（如 coverage-new-lines.js）读取 changed-lines.txt 和 coverage-final.json， # 计算这些行中被覆盖的比例（需解析 lcov 或 V8 覆盖数据结构）
⚠️ 注意：此方案需自行开发解析逻辑（推荐使用 istanbul-lib-coverage 库处理 JSON 报告），且需注意 git diff 行号与源码实际行号的一致性（避免空行、注释干扰）。
✅ 方案二：接入 SonarCloud / SonarQube（推荐用于 CI）
Sonar 系列工具原生支持 "Coverage on New Code" 指标（即“新代码覆盖率”），其定义为：本次 PR/MR 中新增或修改的代码行中，被测试覆盖的比例。配置步骤如下：
- 在项目根目录添加 sonar-project.properties；
- 配置 sonar.javascript.lcov.reportPaths=coverage/lcov.info；
- 将 jest --coverage --coverageReporters=lcov 作为 CI 步骤前置；
- 推送至 SonarCloud 后，仪表盘直接显示「New Code Coverage」百分比，并高亮未覆盖的新行。
该方案开箱即用、结果权威，适用于团队级质量门禁（例如要求新代码覆盖率 ≥ 90%）。
✅ 方案三：IDE 辅助验证（开发阶段快速反馈）
IntelliJ WebStorm / VS Code（配合 Jest 插件）支持“Run with Coverage”，运行后直接在编辑器中以颜色标记：
- ? 绿色：被测试覆盖的代码行；
- ? 红色：未覆盖的代码行；
- ⚪ 灰色：未执行（非 --onlyChanged 下的整文件，而是当前测试实际执行路径）。
结合 --onlyChanged 运行后，聚焦查看变更区域内的红/绿分布，可人工快速确认 newFn 是否 100% 覆盖，而无需关注 oldFn。
总结与建议
- 无银弹：Jest 不原生支持“新代码覆盖率”，任何方案都是组合实现；
- 本地开发 → 优先用 IDE 覆盖率标记 + --onlyChanged 快速验证；
- CI/CD 流程 → 强烈推荐集成 SonarCloud，获取可审计、可设门禁的「New Code Coverage」指标；
- 高阶定制 → 若需完全自动化本地校验，建议基于 istanbul-lib-coverage 开发轻量 CLI 工具，输入 Git diff 结果与 coverage JSON，输出精准新代码覆盖率数值及明细。
最终目标不是绕过 Jest 的限制，而是借助生态工具链，在真实工程约束下，让“新代码必须被覆盖”这一质量原则真正可衡量、可执行、可追溯。
