前端测试覆盖率为什么重要
写前端代码时，改一处功能，另一处莫名其妙出问题的情况太常见了。尤其在团队协作中，没人敢轻易动老代码，怕“牵一发而动全身”。这时候，测试覆盖率就成了你的“安全网”。
测试覆盖率高，不代表代码没 bug，但至少说明你写的测试用例覆盖了大部分逻辑路径。就像给房子装监控，虽然不能阻止小偷，但至少能知道哪里被碰过。
Jest + Istanbul（内置 coverage）
如果你用 React 或 Vue 3 的脚手架创建项目，大概率已经内置了 Jest。Jest 自带测试覆盖率支持，只需加一个参数就能生成报告。
比如在 package.json 里加一行：
"scripts": {
"test:coverage": "jest --coverage"
}运行后会自动生成 coverage 文件夹，里面是 HTML 报告，清楚看到哪些分支、函数没被覆盖。Istanbul 是背后的实际统计引擎，Jest 只是调用了它。
适合大多数中小型项目，配置简单，开箱即用。
Vitest + c8
现在越来越多项目转向 Vite，配套的 Vitest 也火了起来。它速度快，语法和 Jest 高度兼容，搭配 Node.js 内置的 c8（V8 原生覆盖率工具），轻量又高效。
启用方式也很简单，在 vitest.config.ts 中开启 coverage：
export default defineConfig({
test: {
coverage: {
provider: 'v8', // 使用 c8
reporter: ['text', 'html'],
},
},
});跑完测试后，打开 coverage/index.html 就能看到详细覆盖情况。对新项目来说，Vitest 是个更现代的选择。
Cypress + @cypress/code-coverage
如果你用 Cypress 做端到端测试，也能顺手收集覆盖率。配合 @cypress/code-coverage 插件，可以在用户操作页面的过程中，记录哪些代码被执行了。
安装插件并引入后，Cypress 会在测试结束后自动生成覆盖率报告。特别适合验证“用户真实操作路径”是否覆盖到位。
比如你有个表单提交流程，用 Cypress 模拟点击、输入、提交，同时知道这过程中涉及的组件和函数有没有被触发。
Playwright + istanbul-instrumenter
Playwright 虽然不像 Cypress 那样有成熟覆盖率生态，但通过手动注入 istanbul 的 instrumenter，也能实现类似效果。适合对自动化测试要求高的团队。
需要在构建阶段提前对源码插桩（instrument），然后在 Playwright 测试运行后收集数据。配置稍复杂，但灵活性更高。
如何查看和提升覆盖率
生成报告后，重点看三类指标：语句覆盖（Statements）、分支覆盖（Branches）、函数覆盖（Functions）。分支覆盖最难达标，但也是最容易藏 bug 的地方。
比如一个 if-else 判断，只测了 if 成立的情况，else 分支没走，报告里就会标红。这时候补个反向测试用例就行。
别追求 100%，那不现实也没必要。业务核心逻辑保证 80% 以上就很有安全感了。
小技巧：把覆盖率检查塞进 CI
在 GitHub Actions 或 GitLab CI 中加入覆盖率检查，比如低于 70% 就报错，能倒逼团队写测试。
用 jest-coverage-report-action 这类工具，还能直接在 PR 里显示覆盖率变化，谁删了测试一目了然。