JavaScript代码覆盖率怎么测及提升方法

最近发现不少小伙伴都对文章很感兴趣，所以今天继续给大家介绍文章相关的知识，本文《JavaScript代码覆盖率怎么测？如何提升测试覆盖率？》主要内容涉及到等等知识点，希望能帮到你！当然如果阅读本文时存在不同想法，可以在评论中表达，但是请勿使用过激的措辞~

JavaScript代码覆盖率衡量的是测试执行时源码中被实际运行的语句、分支、函数和行，而非测试数量；它不保证质量，但能暴露未触达的逻辑盲区如else分支、catch块等。

JavaScript 代码覆盖率不是“写了多少测试”，而是“运行测试时，源码中哪些语句、分支、函数、行被真正执行过”。它本身不保证质量，但能快速暴露未被触达的逻辑盲区——比如 if 的 else 分支、catch 块、边界条件处理等。

用 jest 开箱测量覆盖率（最常见场景）

Jest 内置 istanbul（通过 babel-plugin-istanbul 注入），开箱即用，无需额外配置即可生成基础报告。

• 确保项目已安装 jest（推荐 v29+），且有基本测试入口（如 test 字段指向 __tests__ 或 src/**/*.test.js）
• 运行命令：

  npm test -- --coverage

  或更完整地：

  npx jest --coverage --coverage-reporters=text-summary --coverage-reporters=lcov

  （后者生成 coverage/lcov-report/index.html 可视化报告）
• 注意：若使用 ts-jest，需确认 tsconfig.json 中 sourceMap 为 true，否则覆盖率可能显示为 0%
• 默认只覆盖 src/ 下文件；若要包含其他目录（如 lib/），需在 jest.config.js 中显式配置 collectCoverageFrom

collectCoverageFrom 配置决定“测什么”，不是“怎么测”

这个数组控制覆盖率统计范围，和测试是否通过无关，但直接影响报告可信度。漏配会导致“假高覆盖率”——比如忘了加 **/*.js，结果只统计了 .test.js 文件自己。

• 典型安全写法：

  collectCoverageFrom: [
    'src/**/*.{js,jsx,ts,tsx}',
    '!src/**/*.d.ts',
    '!src/**/index.{js,ts}',
    '!src/**/__mocks__/**'
  ]

• 避免写 'src/**'——它会包含 node_modules 子目录（即使你没引入）；也别漏掉 !src/**/index.*，这类聚合文件通常不需单独覆盖
• 若用 ESM + exports 字段，且测试跑在 Node.js 环境下，注意 jest 默认不处理 exports，可能导致模块解析失败，进而让对应文件完全不出现在覆盖率中

看懂覆盖率数字：行、函数、分支、语句的区别

终端输出的四列（Statements / Branches / Functions / Lines）含义不同，各自反映不同风险：

• Lines 和 Statements 接近但不等价：空行、注释、export 声明行不计入 Statements，但算在 Lines 统计里
• Branches 是关键短板：一个 if (a && b) 实际产生 3 个分支（true && true，true && false，false && *），但 Jest 默认只按“二元分支”（if/else）统计，复杂布尔表达式需开启 branches: 100 并配合 babel-plugin-istanbul@^6.1.0 才能正确拆分
• Functions 最容易虚高：导出的工具函数若只被测试文件 import 但未调用，仍会计为“已覆盖”；真正要关注的是“被调用且执行到 return 的函数”

提升覆盖率 ≠ 堆砌测试，而是聚焦“不可信路径”

盲目追求 100% 会写出大量无意义断言（比如只调用函数却不验证副作用或返回值）。有效提升应从报告中红色高亮行出发：

• 找到 coverage/lcov-report/index.html 中标红的 else、catch、default、throw 行，针对性补测试用例
• 对异步逻辑（fetch、setTimeout、事件监听），必须用 await 或 done() 确保测试等待完成，否则覆盖率统计会在异步代码执行前就结束
• React 组件中，useEffect 的清理函数、useCallback 的依赖变化、useState 的初始值分支，都是典型低覆盖区域，需用 act() 触发并验证
• 不要 mock 所有外部依赖——比如 mock fetch 却不模拟网络失败场景，catch 块永远无法触发，分支覆盖率就卡在 50%

覆盖率工具不会告诉你逻辑对不对，只会告诉你“这段代码有没有被推着走一遍”。最容易被忽略的是：动态导入（import(...)）、eval、new Function 生成的代码，以及 Web Worker 中的脚本——它们默认不在任何主流覆盖率工具的注入范围内。

今天关于《JavaScript代码覆盖率怎么测及提升方法》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！