前端JS覆盖率达80%关键在聚焦可测性、识别盲区、分层推进；需限定src业务代码统计，忽略不可测逻辑，按模块设差异阈值，优先提升分支覆盖率，嵌入开发流程并用Chrome Coverage与ESLint联动穿透盲区。
前端项目 JS 总体覆盖率达到 80%，关键不是堆测试数量，而是聚焦可测性、识别盲区、分层推进。单纯追求“80%”容易陷入补用例陷阱，真正有效的方式是让覆盖率数字反映真实执行保障力。
先锁定真正该覆盖的代码范围
默认全量统计（比如含 node_modules、polyfill、webpack runtime）会稀释真实业务覆盖率。必须精准限定：
-
只收集 src/ 下业务源码：在 Jest 配置中设置
collectCoverageFrom: ["src/**/*.{js,jsx,ts,tsx}"]，排除__tests__、mocks、types和构建产物 -
忽略已知不可测逻辑：如纯调试语句（
console.log）、类型断言、环境判断（if (process.env.NODE_ENV === 'development')），用/* c8 ignore next */标记，避免拉低指标 - 区分模块优先级：支付、权限、校验等核心模块设高阈值（如分支 ≥90%），工具函数、UI 展示组件可放宽至 70%，整体加权平均自然趋近 80%
从分支覆盖率切入，快速提升“含金量”
行覆盖率（Lines）容易虚高，而分支覆盖率（Branches）更能暴露逻辑缺口。老旧或复杂函数常有“只走通路、不验异常”的问题：
Wjs Uploading Video
下载
将一个或多个视频上传至YouTube。当用户想“上传到YouTube”“发YouTube”“批量上传”“upload to YouTube”“post videos to YouTube”或发布到YouTube时使用此技能。
- 打开 Istanbul HTML 报告，按 “Branch %” 排序，重点看分支覆盖明显低于行覆盖（如 Lines 95%、Branches 42%）的文件
- 对每个标红的
if、switch、try/catch，补一组最小输入触发未执行分支：比如if (user?.token)就测user = null和user = { token: 'abc' } - 对兜底逻辑（
default、catch、|| 'fallback'）单独写用例，确保错误路径真实可触发
把覆盖率嵌入开发流程，防止“测完即丢”
本地跑一次覆盖率没意义，要让它成为日常动作：
立即学习“前端免费学习笔记（深入）”；
- 编辑器里实时看：VS Code 安装 “Jest Runner” 或 “Coverage Gutters”，保存文件后自动运行当前文件测试并高亮未覆盖行
-
CI 中硬性卡点：在
jest.config.js加coverageThreshold: { global: { branches: 80 } }，未达标则构建失败，PR 不可合并 - PR 描述强制说明：要求开发者注明“本次修改影响哪些分支？新增了哪几个测试用例？”，倒逼覆盖意识落地
用工具组合穿透静态盲区
单靠 Jest + Istanbul 会漏掉运行时动态逻辑，需叠加验证：
- Chrome Coverage 面板：More Tools → Coverage，操作真实页面路径（登录、提交、搜索），直接看到哪些 JS 文件/哪几行从未执行——快速发现死代码、未绑定事件、废弃 polyfill
-
ESLint 联动：启用
no-unreachable、no-constant-condition规则，和覆盖率红块交叉比对；若 ESLint 报“不可达”，且那行又标红，基本可安全删除 -
依赖注入改造：对读取
window.config、调用localStorage或全局 API 的函数，改为参数传入或 mockable 依赖，让边界场景（如配置关闭、存储满）可测
