代码覆盖的陷阱

我正在寻找代码覆盖的一些不良副作用的真实世界的例子.

我注意到最近在工作中发生了这种情况,因为有一项政策可以实现100%的代码覆盖率.代码质量肯定在提高,但相反,测试人员似乎正在编写更宽松的测试计划,因为"代码完全经过单元测试".因此,一些逻辑错误成功.它们是一个非常难以调试的因为"代码完全经过单元测试".

我认为这部分是因为我们的工具只进行了声明覆盖.不过,它本来可以花更多时间.

如果有任何人有代码覆盖政策的其他负面影响请分享.我想知道在现实世界中发生了什么样的其他"问题".

提前致谢.

编辑:感谢所有非常好的回应.有一些我会将其标记为答案,但遗憾的是我只能标记一个.

在一句话中:代码覆盖率告诉你你没有测试过的东西,而不是你的东西.

构建有价值的单元测试套件的一部分是找到最重要,高风险的代码并提出它的难题.你想确保把困难的东西作为优先事项.覆盖率数字没有关于代码"重要性"的概念,也没有测试的质量.

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

设置硬性和(可能适得其反)覆盖率目标的问题在于,开发人员可能不得不开始向后弯曲以测试其代码.有代码可测试,然后就是酷刑.如果你通过出色的测试获得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循环的终止条件.

更糟糕的是,可以从仅调用您的应用程序的测试中获得非常高的"覆盖率",而无需费心验证输出或验证输出.

简而言之,低代码覆盖水平肯定表明测试不充分,但高覆盖水平并不表示测试充分或正确.

有时极端情况非常罕见,不值得测试,但严格的代码覆盖规则要求您进行测试.

例如,在Java中,MD5算法是内置的,但从技术上讲,可能会抛出"不支持的算法"类型异常.它永远不会抛出,你的测试必须通过显着的旋转来测试这条路径.

浪费了很多工作.

在我看来,团队从测量代码覆盖率开始的最大危险是它奖励大型测试,并惩罚小型测试.如果您可以选择编写涵盖应用程序大部分功能的单个测试,并编写十个测试单个方法的小测试,则只测量代码覆盖率意味着您应该编写大型测试.

但是,编写一组10个小测试将使您的测试更加简单,并且将比一个大型测试更彻底地测试您的应用程序.因此,通过测量代码覆盖率,特别是在具有不断发展的测试习惯的组织中,您通常可以设置错误的激励措施.