优化你的代码库会让你的代码覆盖率变差

有一些广泛使用的数字和计算，在没有附加信息的情况下，可能会产生错误的印象。例如，身体质量指数（BMI）。它被呈现为一种衡量一个人是否处于健康体重的方法。BMI是通过个人的身高和体重来计算的。通常，BMI在25或以上被认为是超重的。根据这个定义，下面列出的人将被认为是超重的：

比如某 人：

身高 - 6英尺0英寸（183厘米）

重量- 230磅（104公斤）

身体质量指数 - 31.2

如果你得到了更多的信息——比如这个人是2025年作为费城老鹰队的跑卫赢得超级碗的，获得了一枚戒指——你可能会得出结论，也许BMI并不是这个人的健康状况的准确反映。这甚至可能会让你质疑BMI是否有任何价值。

至少根据互联网，那是他的身高、体重和计算出的BMI。我可以舒适地说，巴克利先生非常健康，BMI是一个非常糟糕的用来确定他健康的指标。BMI可能有帮助，但单独来看是一个非常粗略的指标。它不区分肌肉和脂肪——需要更多的信息来做出更明确的判断。

心玥软件公司本文讨论的是在软件开发中突然获得很多青睐的另一个指标：代码覆盖率。

我有多个经验，其中最低代码覆盖率为80%的重要性影响了我的决策、我编写的代码，并且并不总是往好的方向发展。为什么代码覆盖率成为代码质量的代名词？我对此进行了研究和实验。我得出了几点一般性观察：

并非所有文件、功能或应用程序具有相同的价值，但代码覆盖工具会以这种方式对待它们（没有定制的情况下）。

自动化测试并不总是测试您的应用程序最经济有效的方法。

默认的最低代码覆盖率为80%是任意的。

使你的代码更干燥将使你的代码覆盖率更差

您如何组织代码可以提高代码覆盖度指标的准确性——通过使用真实数据和代码的可验证证明

为什么代码覆盖度已成为衡量代码质量的首选指标？

代码覆盖已经存在了很多年。然而，它的使用量增加了，似乎排除了所有其他指标。它已经从一个有用的工具，用于定位需要更多测试的文件，变成了决定代码质量的最终因素。

我的假设是，一定有其他人，即“专家”，比我了解更多，而且我们都在努力达到最低测试覆盖度，一定有一个经过量化、验证、数据证明、测试过的好理由。我搜索过，但没有找到任何将代码覆盖与软件质量联系起来的科学测试证据。

一直对过度依赖代码覆盖率持有一种健康的怀疑态度。马丁·福勒在十多年前就写过关于在没有断言的测试中实现100%代码覆盖率的可能性。即使考虑到没有断言测试的合法担忧，我认为一个整个团队都是恶意行为者，编写没有断言的测试以实现100%代码覆盖率的情况比其他可能性更大。

我个人发现代码覆盖度指标很有用。在编写测试时，它能更容易地识别出最大的漏洞。虽然高覆盖本身并不能验证代码的质量，但低覆盖是一个红旗。当自动化时，这个指标可以防止开发人员合并任何文件低于最低阈值的拉取请求——作为代码质量的把关人。

如果我说我不知道代码覆盖率现在为何如此受重视，那我就在说谎——因为有许多软件供应商营销和推广使用代码覆盖率来自动化衡量质量的工具。一个软件团队可以将其中一个这样的工具添加到管道中，它将作为一个 gatekeeper 来防止开发者合并任何文件低于最低阈值的 pull request。这些工具的使用变得越来越普遍。

简而言之，代码质量的评估是困难的。购买一个自动化并测量单元测试的工具是容易的。

我多次遇到过这样的情景：保持至少80%的代码覆盖率的重要性影响了我的决策、我编写的代码，并且结果并不理想。这让我思考——我们中有多少人被推动去做同样的事情？

不是所有东西都有相同的值，但代码覆盖却把它们平等对待。

关于代码覆盖率的文章可以从“代码覆盖率是一个有缺陷的指标”到“100%的代码覆盖率是不够的”不等。如果你支持至少100%的代码覆盖率，那就表明你对此非常有信心。我可能把自己放在中间某个位置；这可能是一个粗略的测量方法，但我确实认为它有一些价值。

然而，这些文章中的大多数都是在一种开发者中心的视角下，在真空中写的，仿佛唯一重要的事情就是代码。它们的写作仿佛不考虑时间和金钱，每个代码库都是完美的，并且是从头开始写的。这些文章中没有一篇提到编写这些测试的成本，处理某些类型错误的风险管理，以及所有这些投资的回报。

福勒引用的文章之一，“如何错误使用代码覆盖率”写于1997年。

当你将代码覆盖作为衡量测试覆盖的主要（或唯一）指标时，你以完全相同的方式评估每个文件——这个文件达到了最低阈值吗？这些文章没有讨论当将代码覆盖添加到一个已经存在多年的代码库时会发生什么，这在当今经常发生。

除了测试之外，没有考虑其他任务，没有对一个功能相对于另一个功能进行优先级排序。你忽视了代码正在执行的内容及其提供的价值。你没有对某个特定功能失败时会发生什么进行任何财务评估。你将每个文件都视为具有相同价值，并且每个文件都必须达到80%的代码覆盖率。加密用户数据的文件？需要80%的代码覆盖率。允许用户上传其头像的文件？需要80%的代码覆盖率。

如果我要为现有的代码库添加代码覆盖率工具，我更愿意在开始对每个文件随意应用最低阈值之前仔细看看结果。我可以绝对自信地说，不管正在考虑什么应用程序，总会有一些代码需要接近100%的代码覆盖率，但也有一些代码只值得远远低于80%的覆盖率。在每个文件中保持相同百分比的门卫将会导致开发人员为低价值功能编写测试，而不是为具有更高价值的剩余20%的文件编写测试。

其中一些工具可以为应用程序内的不同目录配置不同的阈值。许多团队如果首先手动识别其软件中最重要的部分，并仅对这些部分应用最低阈值，将会获得更高的价值。作为一个代码覆盖工具的使用者，我参与过多个项目，从未见过整个代码库之外的任何默认覆盖。

许多项目在不考虑产品本身的情况下添加这些工具。应该区分在医疗设备上运行的软件和移动约会应用中使用代码覆盖率的情况，区分拥有数百万付费用户的遗留应用程序和发布最小可行产品的初创公司。在所有这些情况下，只有一个数值：80%。

在你的应用中有一些功能，如果它们失败了，对你用户的体验、你的责任或你的利润影响不大。但也有一些功能的失败会带来灾难性的后果。你和你的团队应该更明智地使用代码覆盖工具。请考虑不要盲目地将默认阈值应用于每一个项目和每一个文件。