代码覆盖率是工程实践指标而非js语法特性，反映测试用例对源码的执行覆盖程度；入门重在跑出数字，熟练在于读懂数字背后的问题，关键是以其驱动质量意识和测试习惯。
代码覆盖率不是 JS 的语法特性，而是一种工程实践指标——它反映的是测试用例对源码的执行覆盖程度。入门阶段重在“能跑出数字”，熟练阶段则要“读懂数字背后的问题”。关键不在于工具本身，而在于你如何用它驱动质量意识和测试习惯。
从零开始：先让覆盖率跑起来
新手最容易卡在环境配置上。不需要一上来就集成 CI 或全量统计，按最简路径走：
- 选一个轻量测试框架：Jest 是目前对覆盖率支持最友好、开箱即用的（不用配 babel-jest 就能跑 ES6+ 代码）；
- 初始化命令只要两步：
npm init -y && npm install --save-dev jest，再在package.json里加一行："test": "jest --coverage"； - 写一个最简单的测试文件（如
sum.test.js），哪怕只测1 + 1 === 2，运行npm test就能看到 HTML 报告生成在coverage/lcov-report/index.html； - 重点关注四个基础指标：Lines（行）、Functions（函数）、Statements（语句）、Branches（分支）——入门时先盯住 Lines 和 Functions 是否大于 80%，其他可暂忽略。
理解数字：哪些“未覆盖”真该补，哪些可忽略
覆盖率报告里标红的代码，不一定都要补测试。重点识别三类典型场景：
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
-
防御性代码：比如
if (!obj || !obj.id) return null;这类空值校验，如果业务逻辑中 obj 几乎不可能为 null，强行 mock null 去覆盖反而增加维护成本； -
纯副作用逻辑：如
console.log、localStorage.setItem、第三方 SDK 调用等，它们不改变函数输出，测试价值低，可用// istanbul ignore next注释跳过； -
边界分支：比如
if (status === 'pending') {...} else if (status === 'success') {...} else {...}中的else分支，如果 status 是受控枚举值且已穷举，这个else实际是兜底，可单独验证其存在性而非行为。
进阶实战：把覆盖率变成开发节奏的一部分
真正熟练的表现，是让覆盖率成为你写代码时的自然反馈，而不是发布前的补救任务：
- 写函数前先想：“这个函数有哪些输入路径？哪些分支必须被验证？”——这会倒逼你写出更清晰、更易测的接口；
- 每次提交 PR 前运行
npm test -- --coverage --watchAll=false，只看本次修改文件的覆盖率变化（Jest 支持--changedSince）； - 在 CI 中设硬性门槛：比如
jest --coverage --thresholds '{"lines": 90, "functions": 95}'，低于就失败，但阈值要随项目成熟度逐步抬高； - 定期扫一眼
coverage/lcov-report/index.html里的“未覆盖文件列表”，挑出长期低于 70% 的模块，安排一次小范围重构+补测，比堆砌测试更有效。
避坑提醒：覆盖率 ≠ 质量，但低覆盖率大概率意味着风险
几个常见误解要提前踩住：
- 100% 行覆盖 ≠ 没 bug：可能所有分支都跑了，但参数组合没穷尽（比如只测了正数，漏了负数/边界值）；
- 追求高覆盖率反而写烂测试：为覆盖而写的测试往往耦合实现细节（比如断言内部变量），一旦重构就崩；
- 覆盖率工具不分析逻辑正确性：它只看“是否执行”，不看“执行结果是否合理”，所以必须搭配有意义的
expect()断言。
