核心是借助分支覆盖率识别未触发的条件分支；它专门统计if/else、try/catch、三元运算符等各分支执行情况，能客观暴露“写出来了但从未运行过”的异常路径。
JavaScript 中排查未被执行的异常分支，核心是借助覆盖率工具识别 没有被测试用例触发的条件分支（尤其是 else、catch、throw 分支）。单纯看代码逻辑容易遗漏边界情况，而覆盖率数据能客观暴露“写出来了但从未运行过”的危险路径。
选对覆盖率类型：重点关注分支覆盖率（Branch Coverage）
语句覆盖率（Statement）只能告诉你某行是否执行过；函数覆盖率（Function）只关心函数是否被调用。真正揪出“异常分支没走”的关键是 分支覆盖率 —— 它会标记每个 if/else、try/catch、三元表达式、逻辑运算符（&& ||）中的各个分支是否被执行。
- 例如：
if (x > 0) { a() } else { b() }，分支覆盖率会分别统计x > 0为真和为假的执行情况 -
try { ... } catch (e) { handleError() }中，catch块只有在抛错时才执行，若测试没覆盖错误场景，该分支就显示为“未覆盖” - 使用
jest --coverage --coverage-reporters=html生成 HTML 报告后，在源码旁能看到每行右侧的彩色标记：红色 表示该分支未执行，点击可定位具体哪条分支缺失
让异常分支“显形”：主动构造失败场景写测试
覆盖率低往往不是工具问题，而是测试没设计好。针对常见异常分支，要反向补全测试用例：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
网络请求失败：用
jest.mock('axios')或fetch-mock模拟 404、500、超时、断网等响应，验证catch和错误提示逻辑 -
输入校验不通过：给表单或 API 方法传空值、非法类型、超长字符串、null/undefined，检查是否进入
if (!input)或throw new Error()分支 -
边界条件触发 else：比如循环中
for (let i = 0; i 后跟 <code>if (i === arr.length) {...}，需测空数组场景 -
Promise 拒绝路径：不用
.then().catch()链式调用时，确保有await expect(...).rejects.toThrow(...)或显式catch测试
结合 Istanbul / Jest 的高级能力精准定位
默认覆盖率可能忽略某些结构，需稍作配置提升敏感度：
立即学习“Java免费学习笔记（深入）”；
- 在
jest.config.js中启用collectCoverageFrom并加入"branches": 80门槛，CI 中自动拦截低分支覆盖率的 MR - 对关键模块（如支付、权限校验）添加
/* istanbul ignore else */注释前，先确认该else真的不可达；否则应补测试而非忽略 - 使用
nyc --check-coverage --branches 100强制要求 100% 分支覆盖（适合核心逻辑），快速暴露遗漏分支 - 在 VS Code 中安装 Wallaby.js 插件，可实时看到编辑器内每行/每分支的覆盖状态（绿色已覆盖，红色未覆盖）
别忽视异步与副作用带来的“假覆盖”
有些分支看似覆盖了，实则因异步时机或 mock 不足导致逻辑未真实执行：
-
setTimeout(() => { throw new Error() }, 0)中的throw若测试没await waitFor或done()回调，Jest 可能提前结束，造成“误报已覆盖” - mock 掉外部依赖时，如果只 mock 成功路径（如
mockResolvedValue），却没补充mockRejectedValue，catch分支永远无法点亮 - 使用
act()包裹 React 组件中的异步更新，确保 useEffect、事件处理中的异常分支也被捕获
