覆盖率不是验收标准而是诊断线索；100%语句覆盖不保证逻辑安全与业务正确，需警惕空断言、常量校验、路径幻觉三类无效测试，并以分支覆盖驱动真实场景设计，按业务风险决定测试优先级。
别把覆盖率当验收标准，而要把它当诊断线索。100% 的语句覆盖不等于逻辑安全，更不等于业务正确——它只说明每行代码都被“路过”了一次，没验证是否走对了路、是否扛住了风。
警惕三类典型无效测试
这些测试能拉高数字，但对质量毫无贡献：
-
空断言测试：只调用函数、不检查返回值或副作用，比如
formatDate('2024-01-01')后无任何expect() -
常量校验测试：测
1 + 1 === 2或硬编码输入输出，如expect(add(2, 3)).toBe(5)却从不试add(0, -1)或add(null, 'a') -
路径幻觉测试：为覆盖
if (false) { ... }或// @ts-ignore下一行，专门写用例去“触发”本不该存在或已被废弃的逻辑
用分支覆盖倒逼真实场景设计
语句覆盖容易刷，分支覆盖（% Branch）却很难蒙混过关。它强制你面对真实决策点：
- 看到
if (user?.token && Date.now() 标红？别只补一个 <code>user = { token: 'x', expire: Date.now() + 3600 }，还得补user = null、user = { token: '' }、user = { expire: Date.now() - 1 } - 发现
switch (apiStatus)中default是红色？说明所有测试都只返回预设状态（'success'/'error'），必须 mock 一个后端未定义的状态（如'throttled'）来触发兜底逻辑 - 组件中
useEffect(() => { if (loading) fetch(); }, [loading])的if块标红？说明你从没测过loading = true的情况，而不是删掉这个 effect
把“该不该测”交给业务风险判断
不是所有红行都值得写测试，优先级由实际影响决定：
- 必须补：支付确认弹窗里的风控校验、登录态失效后的跳转逻辑、表单提交前的必填字段拦截
-
可跳过：纯 UI 展示默认值（
name || '游客'）、开发期console.log、已标记/* istanbul ignore next */的 polyfill 兜底 -
该删除：长期未被调用的工具函数、
if (IS_LEGACY) { ... }且IS_LEGACY永远为false、for (let i = 0; i 这类死循环
让测试真正“活”在业务流里
有效测试一定来自真实交互路径，而不是对着代码行数填空：
- 写一个按钮点击测试，不要只测
onClick函数本身，而是模拟用户从看到按钮、到鼠标悬停、再到点击、最后观察 DOM 变化和 API 调用全过程 - 测试 API 错误处理，不是 mock
fetch返回{ error: 'network' }就完事，要确保错误信息真显示在界面上、重试按钮真可点击、日志真上报成功 - 组件测试中，用
fireEvent.change(input, { target: { value: '' } })触发空输入，比手动设input.value = ''更贴近真实行为
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
