三元运算符本身不影响分支覆盖率，关键在于其两个分支是否均被测试覆盖；需通过覆盖率工具定位未执行分支，补充对应测试用例，避免副作用和复杂嵌套，必要时重构为if/else。
三元运算符本身不会导致分支覆盖率未达标，真正影响覆盖率的是它所包裹的表达式是否被完整执行——尤其是当三元条件为真/假时，两个分支（? ... : 后面的两部分）是否都被测试用例覆盖到。
确认哪一分支缺失
运行测试并查看覆盖率报告（如 Istanbul / nyc），定位具体哪一行三元表达式被标记为“未覆盖”。常见情况是：
- 只测试了条件为 true 的情况，
:后的“else 分支”从未执行 - 只测试了条件为 false 的情况，
?后的“then 分支”未执行 - 条件表达式本身有副作用（如函数调用），但该函数未被调用，导致整个分支未进入
为三元运算符补充对应测试用例
不要试图“绕过”三元结构，而是让测试真实触发两种逻辑路径。例如：
源码：
立即学习“Java免费学习笔记（深入）”；
const statusText = isActive ? '在线' : '离线';测试需包含：
-
isActive = true→ 断言statusText === '在线' -
isActive = false→ 断言statusText === '离线'
若三元中含函数调用（如 user.isAdmin() ? doAdminTask() : doUserTask()），确保两个函数在对应测试中被实际调用（可用 jest.mock 或 sinon.spy 验证）。
避免在三元中隐藏复杂逻辑
如果三元右侧表达式过长、嵌套或含副作用，不仅难测，也违背可读性原则。此时应重构为普通 if/else：
- 提升可测性：每个分支独立成块，易于打桩和断言
- 明确执行意图：避免“一个表达式承担多个职责”
- 覆盖率工具能更准确识别分支边界
例如将：
return user.role === 'admin' ? (log('admin login'), fetchAdminData()) : (log('user login'), fetchUserData());改为显式 if/else，再分别测试。
检查测试环境是否干扰条件判断
有时覆盖率“显示未覆盖”，实则是测试中条件恒定（如 mock 返回固定值、环境变量未切换、时间相关逻辑未模拟）。重点排查：
- 被测代码中依赖的变量/函数是否被正确 mock 或赋值
- 是否遗漏了边界值（如
null、undefined、空字符串等触发 false 分支的情况） - 异步逻辑中，三元是否在 promise resolve 前就被求值（导致只走默认分支）
