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.*,这类聚合文件通常不需单独覆盖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() 确保测试等待完成,否则覆盖率统计会在异步代码执行前就结束useEffect 的清理函数、useCallback 的依赖变化、useState 的初始值分支,都是典型低覆盖区域,需用 act() 触发并验证fetch 却不模拟网络失败场景,catch 块永远无法触发,分支覆盖率就卡在 50%覆盖率工具不会告诉你逻辑对不对,只会告诉你“这段代码有没有被推着走一遍”。最容易被忽略的是:动态导入(import(...))、eval、new Function 生成的代码,以及 Web Worker 中的脚本——它们默认不在任何主流覆盖率工具的注入范围内。