如果您强制要求单元测试的代码覆盖率的最低百分比,甚至可能作为提交到存储库的要求,它会是什么?

请解释你是如何得出你的答案的(因为如果你所做的只是选择一个数字,那么我自己也可以完成;)


当前回答

直到几天前,我们的目标是>的80%,但在我们使用了大量生成代码后,我们并不关心%age,而是让审核人员决定覆盖率要求。

其他回答

我最喜欢的代码覆盖率是100%。星号之所以出现,是因为我更喜欢使用工具,允许我将某些行标记为“不算数”的行。如果我已经覆盖了100%“有用”的行,我就完成了。

底层流程是:

我编写测试来测试我能想到的所有功能和边缘情况(通常从文档开始工作)。 我运行代码覆盖工具 我检查了所有没有覆盖的线或路径,以及我认为不重要或无法到达的线或路径(由于防御性编程),我将其标记为不算数 我编写了新的测试来覆盖缺失的行,并在没有提到这些边缘情况时改进文档。

这样,如果我和我的合作者将来添加新代码或更改测试,就会有一条亮线告诉我们是否错过了重要的东西——覆盖率下降到100%以下。然而,它也提供了处理不同测试优先级的灵活性。

如果你的目标是100%的覆盖率(而不是100%测试所有功能),那么代码覆盖率就是一个误导的指标。

你可以通过一次命中所有的线来获得100%。然而,您仍然可能错过测试这些行命中的特定序列(逻辑路径)。 您不能得到100%,但仍然测试了所有80%/频率使用的代码路径。测试每个“抛出ExceptionTypeX”或类似的防御性编程保护是“有就好”而不是“必须”

所以要相信你自己或你的开发人员是彻底的,并覆盖他们代码中的每一条路径。要务实,不要追求神奇的100%覆盖率。如果你用TDD开发你的代码,你应该得到90%以上的覆盖率作为奖励。使用代码覆盖来突出你错过的代码块(如果你使用TDD就不应该发生这种情况。因为您编写代码只是为了通过测试。没有伙伴测试,任何代码都不能存在。)

简单回答:60-80%

长一点的回答: 我认为这完全取决于你项目的性质。我通常通过单元测试每一个实际部分来开始一个项目。在项目的第一次“发布”时,你应该有一个相当不错的基于你所做的编程类型的基础百分比。在这一点上,您可以开始“强制”最小的代码覆盖率。

一般来说,从我读过的几篇工程卓越最佳实践论文来看,单元测试中80%的新代码是产生最佳回报的点。如果超过这个CC%,所付出的努力就会产生更少的缺陷。这是许多大公司所采用的最佳实践。

不幸的是,这些结果大多是公司内部的,所以我没有公开的文献可供参考。

代码覆盖率很好,但功能覆盖率更好。我不喜欢把我写的每一行都写一遍。但是我相信编写100%的测试覆盖我想要提供的所有功能(即使是我自己带来的额外的很酷的功能,这些功能在会议中没有讨论)。

我不关心我的代码是否会在测试中被覆盖,但我关心的是我是否会重构我的代码并最终具有不同的行为。因此,100%的功能覆盖率是我的唯一目标。