问代码覆盖率的陷阱

EN

一句话:代码覆盖率告诉你你肯定没有测试过的东西，而不是你已经拥有的东西。

构建有价值的单元测试套件的一部分是找到最重要的、高风险的代码，并对其提出困难的问题。你想要确保困难的东西优先工作。覆盖率数字没有代码的“重要性”的概念，也没有测试的质量。

根据我的经验，您将编写的许多最重要的测试都是那些几乎不会添加任何覆盖率的测试(边缘情况会在这里和那里添加一些额外的%，但会发现大量的bug)。

设置硬的和(可能适得其反的)覆盖目标的问题是，开发人员可能不得不开始向后弯下腰来测试他们的代码。让代码变得可测试，然后就是折磨。如果你用伟大的测试达到了100%的覆盖率，那就太棒了，但在大多数情况下，额外的努力是不值得的。

此外，人们开始痴迷于/摆弄数字，而不是关注测试的质量。我见过写得很差的90+%覆盖率测试，就像我见过只有60-70%覆盖率的优秀测试一样。

同样，我倾向于将覆盖率作为一个指标，以确定还没有对进行测试。

仅仅因为有代码覆盖率并不意味着您实际上正在测试通过该函数的所有路径。

例如，此代码有四个路径：

if (A) { ... } else { ... }
if (B) { ... } else { ... }

然而，只有两个测试(例如，一个A和B为真，一个A和B为假)就会给出"100%的代码覆盖率“。

这是一个问题，因为一旦你达到了神奇的100%数字，就倾向于停止测试。

根据我的经验，代码覆盖率工具最大的问题是有人会成为“高代码覆盖率”等同于“良好测试”的信念的受害者。大多数覆盖率工具只提供语句覆盖率指标，而不是条件、数据路径或决策覆盖率。这意味着可以在像这样的代码上获得100%的覆盖率：

for (int i = 0; i < MAX_RETRIES; ++i) {
    if (someFunction() == MAGIC_NUMBER) {
        break;
    }
}

..。而不测试for循环上的终止条件。

更糟糕的是，简单地调用您的应用程序的测试可能会获得非常高的“覆盖率”，而不会费心验证输出或错误地验证它。

简单地说，低代码覆盖率水平肯定是测试不足的迹象，但高覆盖率水平并不是充分或正确测试的迹象。