代码覆盖率不是一刀切的规则

发布: 6天前 (2026年2月3日 GMT+8 02:54)

3 分钟阅读

原文: Dev.to

Source: Dev.to

通用覆盖率百分比的神话

对“85 % 代码覆盖率”的执念通常来自于远离真实软件和系统架构的人群。这是一种打勾思维，往往是受从众心理驱动，而非工程判断。

如果你的代码运行在接近硬件层面，没有表现层，并且大多是确定性逻辑，那么 60–70 % 的单元测试覆盖率已经相当稳固。再往上提升会很快出现收益递减。

在大型项目——尤其是外包项目——中，覆盖率指标容易被玩弄。只要函数被调用，测试通过，百分比就上升。管理层欢呼，发放奖励，却没有真正验证任何有意义的东西。

对于任何拥有真实 UI 的软件，单元测试超过约 40 % 往往是对项目成本的负担。

任何可以转化为纯函数的逻辑都应拥有 100 % 的单元测试。

任何可以被 mock 的东西就进行 mock。

其余所有内容都交给端到端测试。
过去的 E2E 测试往往是脆弱的浏览器自动化脚本。那个时代已经结束。如今我使用自己的产品 ehAye Engine，配备内置浏览器自动化，来运行完整的端到端流程。会话被完整记录，每个页面和标签页都会截取截图，并标记异常。

在任何部署之前，必须让一个与生产环境相同但私有的预演环境通过完整的 E2E 套件，才能解锁上游合并——不设例外。

当我知道 E2E 正在验证系统行为的 100 % 时，我对 20 % 的单元测试覆盖率完全没有问题。

关键是度量，但让 ehAye Engine 来完成繁重的工作：记录一切，捕获截图，解说正在发生的事情。结果是可重复、快速且高信噪比的测试。