文档结构  
可译网翻译有奖活动正在进行中,查看详情 现在前往 注册?
原作者:Greg L. Turnquist (December 27, 2016)    来源:greglturnquist.com [英文]
班纳睿    计算机    2017-01-03    0评/297阅
翻译进度:71%   参与翻译: 班纳睿 (5)

最近,我跟我的几个朋友在Twitter上聊天,重谈起了测试覆盖率的问题。我不以为然。 刚要准备好开始咆哮,我才记起来我之前在Python测试手册 中已经讨论过测试覆盖率的诸多缺陷 所以我就想,也许把部分摘录过来会比较好些。

从《Python测试手册》第九章节开始....

****

覆盖率并不是一切

你已经知道如何运行覆盖率报告了。但是不要想当然地认为越多的覆盖率就自然越好了。为了以为追求覆盖率却影响测试质量绝对是失败的最好配方了。

如何去做呢…

覆盖率报告可以提供良好的反馈。它们会告诉我们什么得到了测试,什么有没有。但是只是因为一行的代码得到了测试并不意味着它就做了所有它应该去做的事。

第 1 段(可获 1.64 积分)

你是否曾经在休息室里试图去吹嘘覆盖率的百分比分数? 为良好的覆盖率感到自豪并非不可取,但是当因此而导致使用这些统计数字去比较不同的项目时,我们就是在误入歧途了。

它是怎么工作的…

覆盖率报告是应该结合他们所针对运行的代码上下文来阅读。这些报告给我们展示了什么被覆盖到了,而什么还没被覆盖到,但是这并不是说事情就完事了。相反的,事情才刚刚开始。我们需要看看什么被覆盖了,并且分析这些测试是如何适应系统的。

很显然一个模块如果有 0%的覆盖率,那就说明我们还有工作要做。 但是当我们有70%的覆盖率那又意味着什么呢?我们需要编写代码去追逐那剩余的30%吗?当然我们会的!但是关于如何看待这个问题,有两种不同学派的想法。一种是正确的,另一种是错误的:

第 2 段(可获 2 积分)
  • 第一种方式是,写针对那些明确没有被覆盖到的部分的测试,而要试图避免重复原来的那70%。也就是说,早已在其他测试中被覆盖的测试代码是对资源的低效的利用。
  • 第二种方式就是,写针对代码所期待处理但还没有被处理的的场景的测试。没有被覆盖的部分应该能够提示我们还有什么场景没有被测试到。

第二个是正确的方式。好了,我承认我以一种引领时尚的方式写了那些。但是关键是很容易找到有哪些没有被测试到,并且也很容易写出尽快缩小差距的测试来。

第 3 段(可获 1.58 积分)

There’s more…

Python gives us incredible power to monkey patch, inject alternate methods, and do other tricks to exercise the uncovered code. But doesn’t this sound a little suspicious? Here are some of the risks we are setting ourselves up for:

  • The new tests may be more brittle when they aren’t based on sound scenarios.
  • A major change to our algorithms may require us to totally rewrite these tests.
  • Ever written mock-based tests? It’s possible to mock the target system out of existence and end up just testing the mocks.
  • Even though some (or even most) of our tests may have good quality, the low quality ones will cast our entire test suite as low quality.
第 4 段(可获 1.5 积分)

The coverage tool may not let us “get away” with some of these tactics if we do things that interfere with the line counting mechanisms. But whether or not the coverage tool counts the code should not be the gauge by which we determine the quality of tests.

Instead, we need to look at our tests and see if they are trying to exercise real use cases we should be handling. When we are merely looking for ways to get more coverage percentage, we stop thinking about how our code is meant to operate, and that is not good.

Are we not supposed to increase coverage?

第 5 段(可获 1.33 积分)

我们应该通过改进我们的测试,覆盖更多的场景,并删除不再支持的代码来增加覆盖率。这些事情都能使我们获得更好的质量。

单纯为了覆盖率而增加覆盖率并不会提高我们系统的质量。

但是我想炫耀一下我的系统的覆盖率!

我认为因拥有好的覆盖率而庆祝是没问题的。与你的经理分享覆盖率报告也是可以的。但不要让它消耗你。

如果你开始每周都要发布覆盖率报告,先仔细检查你的动机。同样,如果你的经理要求发布该报告,你也要同样这样做。

第 6 段(可获 1.3 积分)

如果你试图对比你的系统和其他系统的覆盖率有什么不同,那么就要注意了!除非你同时熟悉两个系统的代码并且真正明白报告的底线, 否则你可能就是在危险的领域里徘徊了。你可能会陷入错误的竞争中,从而导致你的团队写出脆弱的测试来。

****

你的观点呢,是同意?还是不同意?请在评论区,自由的发表您对关于测试覆盖率报告中的优缺点的看法吧。

第 7 段(可获 1.04 积分)

文章评论