What
代码覆盖率是测试跑完之后，一个工具统计出来的比例：测试执行时，有多少代码真的被跑到了。
最常见的是 line coverage，也就是“有多少行代码被测试执行过”。还有 branch coverage，关注 if/else、三元表达式、异常分支这些路径有没有被跑到。
How to read it
如果一个项目说覆盖率是 80%，大概意思是测试执行时跑到了 80% 的代码。但这不等于“代码 80% 没问题”，它只说明测试碰到了这些代码。
一个很高的覆盖率也可能没什么用：
expect(result).toBeDefined()这种测试确实会跑到代码，但没有认真检查结果是否正确。
反过来，覆盖率偏低通常是明显信号：有很多代码路径根本没有测试保护。以后改这些地方时，很容易在不知道的情况下破坏功能。
What counts as covered
覆盖率统计不关心代码是被哪一种测试跑到的，只关心测试运行时有没有实际执行到那段代码。
所以业务逻辑测试跑到的代码会算进覆盖率，极端 case / edge case 测试跑到的异常分支也会算进覆盖率。比如某个 if/else 只有在用户权限不足、输入为空、网络失败、余额不够这种情况下才会进入，那么只有测试真的构造了这些场景，对应分支才算被覆盖。
if (user.age < 18) {
return "minor"
} else {
return "adult"
}如果测试只测了 age = 20，那就只跑到了 else 分支。line coverage 可能看起来还可以，但 branch coverage 会提醒你 age < 18 这条路径还没有被测试跑到。
这也是为什么业务逻辑测试和极端测试很重要：它们通常是在把“平时不容易走到，但一旦错了很危险”的路径跑起来。覆盖率能提醒这些路径有没有被测试碰到，但仍然不能保证测试断言写得好。
Why teams care
在团队协作里，覆盖率通常不是为了追一个漂亮数字，而是为了降低合并风险：
- reviewer 可以更放心地看 PR。
- CI 可以自动挡住缺少测试的改动。
- 重构时更容易发现行为被改坏。
- 线上出 bug 后，可以补一个测试防止同类问题再次出现。
Practical note
覆盖率阈值要看项目阶段。视频里提到 95%，这是比较严格的标准，适合对质量要求很高的代码库。个人项目或早期项目可以先从更现实的阈值开始，比如 70% 或 80%，但关键路径最好认真覆盖。
不要把覆盖率当成唯一目标。更好的问题是：这次改动最容易坏的路径，有没有测试守住？