专栏首页ThoughtWorks都100%代码覆盖了,还会有什么问题?

都100%代码覆盖了,还会有什么问题?

(图片来自:http://t.cn/R06rQHi)

引言

很多人看到这个标题时,都会想“你都100%代码覆盖了,怎么还会有问题呢?”

让我们看一下代码例子:

public class TestCalculator {

  public Double add(Double a, Double b) {

    return a + b;}

}

再看看用junit写出的测试代码:

@Test
public void testAdd() {

  Double a = new Double(1);
       
  Double b = new Double(2);
       
  Double c = new Double(3);
       
  assertEquals(c, testCalculator.add(a, b));

}

当我们使用EclEmma或者Jacoco来进行覆盖测试时,对于这个类,我们将得到100%测试覆盖率。

一切看起来都那么的完美,真是这样的吗?

好吧,让我们来来看看另一个测试,当其中一个变量为null时,返回值将会是什么?

@Test
public void testAddNullPointerException() {

  Double a = new Double(1);

  Double b = null;

  Double c = new Double(3);

  assertEquals(c, testCalculator.add(a, b));

}

好了,你会发现尽管覆盖率为100%,但程序却抛出了NullPointerException。

那么肯定有人会问,这样的话单元测试覆盖率的高低都不能作为衡量项目代码质量的指标,那么我们要单元测试还有什么用?

首先,我想我们可能搞错了测试覆盖的定义。

我们先听听Martin Fowler对于测试覆盖的定义:

Test coverage is a useful tool for finding untested parts of a codebase. Test coverage is of little use as a numeric statement of how good your tests are.

(图片来自:http://t.cn/R06jK5U)

他认为:把测试覆盖作为质量目标没有任何意义,我们应该把它作为一种发现未被测试覆盖的代码的手段。


所以100%的代码覆盖率还值得追求吗?

当然,这应该是每个程序员毕生的追求之一,但是如果从项目角度考虑ROI(投入产出比),对于需要快速上线的短期项目,需要注重的是让测试覆盖核心功能代码。如果你的项目是一个长期项目,那么高覆盖率是非常有必要的,它意味着高可维护性,以及更少的bug。(前提是你的测试采用TDD/BDD方式编写,我见过将测试代码写的一团糟的人,看着他的代码,我宁愿重新写一遍。)

那么对于一个项目来说,覆盖率应该达到多少?

其实没有适用于所有项目的数值,每个项目都应有自己的阈值,但共性是,测试必须覆盖主要业务场景,代码的逻辑分支也必须尽可能的覆盖。

如何改进你的项目代码覆盖率?

首先我们要阅读和理解项目代码,找出其中需要测试并且与业务强相关的代码,结合sonar等代码质量管理平台,从代码编写规范、复杂度、重复代码等方面进行代码重构,进一步提高项目的可维护性与可读性。

这也意味着重构,重构的同时,你需要更多的测试来保证你重构代码的正确性。

其次要对code coverage进行度量分析,那么我们应该怎么度量code coverage?

一般来说我们从以下四个维度来度量,如上图所示:

  • 行覆盖率(line coverage):度量被测代码中每个可执行语句是否都被执行到,但不包括java import,空行,注释等。
  • 函数覆盖率(function coverage):度量被测代码中每个定义的函数是否都被调用。
  • 分支覆盖率(branch coverage):度量被测代码中每一个判定的分支是否都被测试到。
  • 语句覆盖率(statement coverage):度量被测代码是否每个语句都被执行。

所以行覆盖率的高低不能说明项目的好坏,我们要从多方面进行思考,一般我们遵循的标准应是:函数覆盖率 > 分支覆盖率 > 语句覆盖率

代码覆盖率最重要的意义在于:

  • 阅读分析之前项目中未覆盖部分的代码,进而反推在前期QA以及相关测试人员在进行黑盒测试设计时是否考虑充分,没有覆盖到的代码是否是测试设计的盲点,为什么没有考虑到?是需求或者UX设计不够清晰,还是测试设计的理解有误。
  • 检测出程序中的废代码,可以逆向反推代码设计中不合理的地方,提醒设计/开发人员理清代码逻辑关系,提升代码质量。
  • 代码覆盖率高不能说明代码质量高,但是反过来看,代码覆盖率低,代码质量绝对不会高到哪里去,可以作为测试自我审视的重要工具之一。

结束语

单元测试的覆盖率并不只是为了取悦客户或者管理层的数据,它能够实实在在反应项目中代码的健康程度,帮助我们更好的改善了代码的质量,增加了我们对所编写代码的信心。


本文分享自微信公众号 - 思特沃克(ThoughtWorks),作者:齐磊

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2017-09-26

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • TW洞见|满足善变用户:追求用户价值覆盖率,而不是....

    今日TW洞见 文章作者及图片来自ThoughtWorks:伍斌。 本文所有内容,包括文字、图片和音视频资料,版权均属ThoughtWorks公司所有,任何媒体、...

    ThoughtWorks
  • 从分布式计算到分布式训练

    对计算机来讲,所谓的计算,不过是将存储在各个地方的数据通过数据总线进行传输,然后经过算术逻辑单元执行一系列预设好的规则,最终再将输出写入到某个位置。 在计算能力...

    ThoughtWorks
  • 真正的敏捷工作流 —— GitHub flow

    7991 年,随着极限编程(Extreme programming)方法论的提出,持续集成(Continuous integration)也随之成为一项标准化的...

    ThoughtWorks
  • AI 连程序员的饭碗也要抢?未来计算机可以给自己编程序

    人工智能的前景是无量的。家用服务机器人、亚马逊的智能 Echo、无人机送货、精准的医疗诊断……在 AI的帮助下,这些智能设备正以飞快的速度走进每家每户。人们可以...

    BestSDK
  • AI编程进中小学课程:教育部今年起评测2万学生信息素养

    高校方面,文件也提出加强对有关“双一流”建设高校的指导,继续加强网络空间安全、人工智能相关学科建设。实施“卓越工程师教育培养计划2.0”,加快推进网络安全领域新...

    新智元
  • Angularjs基础(四)

    AngularJS过滤器     过滤器可以使用一个管道符(|)添加到表达式和指令中。       AngularJS过滤器可用于转换数据:    ...

    用户1197315
  • 一周AI回顾 | 南沙设立人工智能视觉图像研发中心,旷视科技C轮筹资4.6亿美元

    本期一周AI看点包括行业热点、投融资、业界观点、技术前沿以及应用等方面。 行业 中科曙光研制出首款搭载寒武纪AI芯片的人工智能服务器 中科曙光近日成功研制出首款...

    AI科技大本营
  • 如何在chrome中实时修改JS

    有时候,我们需要去研究人家网站的运行机制,这就免不了要在他们的前端脚本里插入一些调试代码看看运行效果。在chrome65以前,我们可以打开目标网页的开发者工具—...

    流量黑客
  • Angularjs基础(五)

    AngularJS Select(选项框)     AngularJS 可是使用数组或对象创建一个下拉列表选项。 使用ng-options创建选项框    ...

    用户1197315
  • 【支付系统设计从0到1】写在前面

    支付是商业变现必不可少的环节,而每个公司,因为业务形态并不太一样,导致开发的支付系统不尽相同。

    金融民工小曾

扫码关注云+社区

领取腾讯云代金券