代码覆盖的陷阱 [英] Pitfalls of code coverage

问题描述

我正在寻找有关代码覆盖范围的不良副作用的现实示例。

I'm looking for real world examples of some bad side effects of code coverage.

我最近注意到这种情况正在发生，因为有一项政策要求达到100％代码覆盖率。可以肯定，代码质量一直在提高，但是相反，测试人员似乎正在编写更多宽松的测试计划，因为代码已经完全进行了单元测试。结果，一些逻辑错误得以解决。他们是一个非常大的调试难题，因为代码完全经过了单元测试。

I noticed this happening at work recently because of a policy to achieve 100% code coverage. Code quality has been improving for sure but conversely the testers seem to be writing more lax test plans because 'well the code is fully unit tested'. Some logical bugs managed to slip through as a result. They were a REALLY BIG PAIN to debug because 'well the code is fully unit tested'.

我认为部分原因是因为我们的工具仅进行了语句覆盖。

I think that was partly because our tool did statement coverage only. Still, it could have been time better spent.

如果有人对代码覆盖政策有其他负面影响，请分享。我想知道现实世界中还会发生什么其他问题。

If anyone has other negative side effects of having a code coverage policy please share. I'd like to know what kind of other 'problems' are happening out there in the real-world.

预先感谢。

编辑：感谢所有非常好的回复。我会将其中一些标记为答案，但很遗憾，我只能标记一个。

Thanks for all the really good responses. There are a few which I would mark as the answer but I can only mark one unfortunately.

推荐答案

告诉您您确实没有进行过测试，而不是已经进行过的测试。

In a sentence: Code coverage tells you what you definitely haven't tested, not what you have.

构建有价值的单元的一部分测试套件正在查找最重要的高风险代码，并提出一些棘手的问题。您要确保将困难的工作作为优先事项。覆盖率数字既没有代码重要性的概念，也没有测试质量的概念。

Part of building a valuable unit test suite is finding the most important, high-risk code and asking hard questions of it. You want to make sure the tough stuff works as a priority. Coverage figures have no notion of the 'importance' of code, nor the quality of tests.

根据我的经验，您将要编写的许多最重要的测试几乎根本没有增加任何覆盖率的测试（边缘情况在此处增加了一些额外的百分比，在那里，但找到大量错误）。

In my experience, many of the most important tests you will ever write are the tests that barely add any coverage at all (edge cases that add a few extra % here and there, but find loads of bugs).

设置硬目标（可能适得其反）的覆盖范围问题是，开发人员可能不得不开始弯腰测试代码。使代码可测试，然后就折磨了。如果您通过出色的测试达到了100％的覆盖率，那就太好了，但是在大多数情况下，付出额外的努力就不值得了。

The problem with setting hard and (potentially counter-productive) coverage targets is that developers may have to start bending over backwards to test their code. There's making code testable, and then there's just torture. If you hit 100% coverage with great tests then that's fantastic, but in most situations the extra effort is just not worth it.

此外，人们开始迷恋/摆弄数字而不是专注于测试的质量。我见过覆盖率超过90％的笔试不佳，正如我见过覆盖率只有60-70％的出色测试一样。

Furthermore, people start obsessing/fiddling with numbers rather than focussing on the quality of the tests. I've seen badly written tests that have 90+% coverage, just as I've seen excellent tests that only have 60-70% coverage.

同样，我倾向于将覆盖率视为肯定未经测试过的指标。

Again, I tend to look at coverage as an indicator of what definitely hasn't been tested.

这篇关于代码覆盖的陷阱的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！