TestCoverage

2012年4月17日

我不时地听到人们问他们应该以测试覆盖率(也称为代码覆盖率)的价值为目标,或者自豪地陈述他们的覆盖率级别。这种说法没有抓住要点。测试覆盖对于寻找代码库中未测试的部分是一个有用的工具。测试覆盖率作为测试好坏的数字声明用处不大。

我们先来看表述二。我听说过一些地方可能会说“如果覆盖率低于87%,你就不能投入生产”。我听一些人说,你应该使用TDD之类的东西,并且必须得到100%的覆盖率。一位智者曾经说过:

我希望有高水平的报道。有时经理们需要一个。有一个微妙的区别。

--Brian Marick

如果你将一定程度的覆盖率作为目标,人们就会努力实现它。问题在于,高覆盖率数字太容易通过低质量的测试达到。在你最荒谬的水平上AssertionFreeTesting.但即使没有这些,您也会得到很多测试,寻找很少出错的东西,从而分散您对真正重要的东西的测试。

与编程的大多数方面一样,测试也需要深思熟虑。TDD是一种非常有用的工具,但肯定不足以帮助您获得良好的测试。如果您经过深思熟虑并且测试良好,我希望覆盖率在80或90以上。我对100%之类的东西会产生怀疑——这可能会让人觉得有人编写测试只是为了让覆盖率数字满意,却不考虑他们在做什么。

当然,人们关注覆盖率数字的原因是,他们想知道自己的测试是否足够。当然,低覆盖率(比如低于一半)是麻烦的信号。但高数字不一定意味着什么,也不一定会导致ignorance-promoting仪表板.测试的充分性比覆盖率能回答的要复杂得多。我想说你做了足够的测试,如果以下是真的:

  • 你很少会有bug逃到生产环境中,
  • 在更改一些代码时,您很少会因为担心这会导致产品bug而犹豫不决。

你会测试太多吗?你当然可以。如果您可以删除测试,但仍然有足够的测试,那么您测试太多了。但这是一件很难察觉的事情。测试太多的一个标志是测试是否减慢了您的速度。如果对代码的简单更改似乎导致对测试进行过长的更改,这表明测试存在问题。这可能并不是因为您测试了太多的东西,而是因为您的测试中有重复。

有些人认为如果测试时间太长,那么测试就太多了。我不太相信这个论点。您总是可以将缓慢的测试转移到部署管道的后期阶段,甚至可以将它们从管道中取出并定期运行它们。做这些事情将减缓来自那些测试的反馈,但这是构建时间与测试信心之间的权衡。

那么覆盖率分析的价值是什么呢?它可以帮助你找到哪些代码没有被测试。[1]经常运行覆盖工具并查看这些未测试的代码是值得的。他们会担心你不测试他们吗?

如果您的测试套件的某个部分在覆盖率可以检测到的程度上是弱的,那么它也可能在覆盖率无法检测到的程度上是弱的。

--Brian Marick

进一步的阅读

Brian Marick有一篇很好的文章代码覆盖的误用.值得一读特维斯精辟的评论

笔记

1:这里的“你”是指编写测试的人。覆盖率对于管理没有什么价值,因为您需要一个技术背景来理解测试是好的还是未发现的代码是一个问题。