核心是验证关键逻辑是否被更稳、更全地覆盖，而非单纯比较数字；需建基线、统一度量口径，重点关注分支/函数/条件覆盖率变化，并用增量分析锁定影响区。
在架构重构前后对比 JavaScript 代码覆盖率，核心不是比“数字涨没涨”，而是看“关键逻辑是否被更稳、更全地验证”。重构本身不改变功能，但会改变代码结构——比如拆分函数、提取模块、引入新抽象层。这些变化会让原有覆盖率报告失真（例如旧测试可能无法执行新模块），也暴露出过去没覆盖到的路径。下面从实操角度讲清楚怎么做。
重构前先建基线：锁定可比范围
别直接跑全量覆盖率就截图存档。要确保前后两次统计口径一致：
- 用同一套工具链（如 Jest + Istanbul/Canyon），禁用自动升级插件版本
- 排除构建产物、类型声明文件（.d.ts）、测试文件本身，只统计源码目录（如 src/**/*.{js,ts}）
- 固定测试运行环境：Node 版本、Jest 配置（特别是 collectCoverageFrom 和 coveragePathIgnorePatterns）
- 对有动态加载或条件编译的模块（如按环境 import 的 config），提前 mock 或统一入口，避免覆盖率抖动
重点盯三类指标变化，而非只看总百分比
重构后行覆盖率可能下降，但分支/条件覆盖率反而上升——这往往说明重构暴露了旧测试的盲区。重点关注：
- 分支覆盖率变化：尤其关注新拆出的函数、新引入的 if/switch 分支。比如把一个大函数拆成 validate()、transform()、send() 后，原来隐藏在 if-else 里的错误路径可能变成独立函数的显式返回分支，这时分支覆盖率数值下降反而是好事（说明之前漏测了）
- 函数覆盖率缺口：重构后新增的工具函数、Hook、自定义 Hook 是否被调用？Jest 报告里 Uncovered functions 列表能快速定位“写了但没测”的新模块
- 路径敏感区域的条件覆盖率：比如支付校验逻辑中 if (amount > 0 && user.balance >= amount && !user.isFrozen)，重构后若拆成多个校验函数，需确认每个子条件（amount > 0、user.balance >= amount 等）在 false 场景下是否仍被覆盖
用增量覆盖率锁定重构影响区
单纯比两个完整报告，容易被无关变更干扰。推荐结合 Git 做增量分析：
- 在重构提交前，基于 main 分支生成 baseline 报告
- 重构完成后，在当前分支运行 jest --coverage --changedSince=main（Jest 内置支持）或用 Canyon 的 diff coverage 功能
- 聚焦报告中 “Changed files” 标签页：只看被修改/新增的文件，检查它们的语句、分支是否 100% 覆盖；未修改文件的覆盖率波动可忽略
- 对新增文件，强制要求函数+分支双 100%，避免“重构引入新裸奔代码”
把覆盖率差当成重构验证点，而不是扣分项
重构后覆盖率下降，别急着补测试。先问三个问题：
- 下降的是哪几行？是废弃代码（如删掉的旧逻辑），还是新抽象层里没被调用的 fallback 分支？
- 有没有因为模块解耦，导致原测试用例无法触达新内部函数？比如原来通过组件 props 触发的逻辑，现在移到自定义 Hook 里，测试就得改写为 renderHook
- 是否因移除了冗余判断（如 if (x !== undefined) 改为 TypeScript 类型保障），让某些分支自然消失？这种下降是质量提升
真正该补测试的，是重构后暴露的新分支、新错误路径、新边界条件——这些才是重构带来的真实风险点。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
