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）含义不同，各自反映不同风险：
立即学习“Java免费学习笔记（深入）”；
-
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 中的脚本——它们默认不在任何主流覆盖率工具的注入范围内。
