有必要追求 100% 的单测覆盖率吗？

【编者按】本文主要讨论了一个项目的开发过程中对测试覆盖率的要求以及其带来的挑战，强调了 100% 的测试覆盖率的重要性和好处，尤其是在避免隐藏错误和减少回归问题方面的作用，在团队规模扩大时尤为重要。

原文链接：https://brandur.org/fragments/100-percent-coverage

作者 | brandur 译者 | 明明如月

责编 | 夏萌

出品 | CSDN（ID：CSDNnews）

我们正在开发一个项目，该项目不仅要求达到 100% 的测试覆盖率，还要求达到 100% 的分支覆盖率。这个过程颇为艰难。你的任何一次改动都可能无意中影响到测试覆盖率。

因此，如果一个标准的开发流程是：

1. 添加功能

2. 编写测试/修复bug，那么在这个项目中，你需要遵循一种三步流程：添加功能；编写测试/修复bug；追踪每一个未被覆盖的分支，并编写逐渐复杂的测试用例以覆盖这些分支。

我清楚地知道并非只有我对此持有怀疑态度。业务代码覆盖率的要求是开发人员常见的抱怨之一，与测试组件运行速度缓慢或繁琐的管理问题一样常见。

然而，100% 的测试覆盖率无疑是有益的，尤其是在如 Ruby 这样的语言中。未执行的分支可能隐藏着严重的错误，这些错误虽然能够被解释器接受，但一旦执行，就可能导致生产环境崩溃。

在思考 100% 覆盖率是好是坏的过程中，我突然意识到，人们往往忽视了一个重要的方面，那就是它具有棘轮效应，一旦实现 100% 测试覆盖率的习惯形成，就具有不可逆性，很难再回到之前的状态。我们还有一个项目，是由一个只有两人的小团队来支持，不要求达到 100% 的覆盖率。它的测试组件运行得很好，我们采取了一种非正式的策略，即尽可能详尽的测试，但并不强求 100% 的覆盖率。而保证这一点的唯一方法就是依赖每个开发者的良好自觉性，以及一定程度的代码审查。如果我们要添加第三个成员，我们希望他们能分享我们对测试的审美偏好，或者至少能学会模仿，但最终会发现这通常无法保证。如果这个第三个成员在他们任职的几个月后还常常忽视测试，未经充分测试的功能将变得越来越多，由更改带来的风险也随之增大，我们预见到回归问题将变得更多。（注：回归问题指：在进行软件开发过程中，对已有功能或代码的更改可能引入新的错误或导致已有功能的失效。）

虽然我在上面用一个团队从两个人扩展到三个人的情况说明这个问题，但一旦你的团队规模达到 10人甚至 100 人，你必然会碰到一些对测试理解不深的人。

尽管追求 100% 的测试覆盖率可能会让人感到不愉快，但我还是更倾向于认为它是有益的。测试本身对防止回归问题非常有效，在更大的团队中，设定严格的测试基准可能更为重要。

你们认为追求 100% 的单测覆盖率有必要吗？

▶仅用 5 小时！中国团队推出「全球首颗」AI 全自动设计 CPU，性能比肩 Intel 486！

▶ “盗窃”而来的 3000 亿单词？ChatGPT 摊上事了，遭索赔 30 亿美元！

▶ QQ 用 Electron 重构后，终实现 Linux、macOS、Windows 三端架构统一！ 返回搜狐，查看更多

责任编辑：