返回 登录
0

100%代码覆盖率的悲剧

阅读50538

原文:http://labs.ig.com/code-coverage-100-percent-tragedy
作者:Daniel Lebrero
翻译:Aladdin

本文Daniel Lebrero在大数据团队担任IG的技术架构师。拥有超过15年的Java经验和4年的Clojure经验,他现在是函数式编程的大力倡导者。 以下为译文:


有趣的是,我对测试的观点正在发生变化。十五年来,我一直在推广TDD(测试驱动开发,过去也被称为测试优先方式),或至少对于开发者来说,写一些单元测试。不过,最近我发现自己更常说:“你为什么要写测试?“而不是“你应该写测试”。

到底是怎么回事?

在办公室周围走走时,开发人员要求我帮助他进行单元测试。看来他在使用Mockito测试以下代码时遇到了麻烦:

img

当我回应:“你不需要测试。”,他感到非常惊讶。

“但我不得不测啊!” 他说。“不测试我怎样知道这段代码能运行啊?”

“这段代码的功能看起来很简单,没有条件,没有循环,没有转换,没有任何复杂的东西,只是一段简单的老胶水代码。

“但不测试的话,任何人都可以来更改这段代码啊!”

“好,那我们试想来了个无知的开发者,试图更改这些简单的代码,如果相关的单元测试发生了变化,他会做什么,他只会删除它。“

“但是如果你非要写测试怎么办呢?”

“在这种情况下,我会这样写测试:”

img

“但是你没有使用Mockito啊!”

“那又怎么样?Mockito在这种情况下不仅没有帮助,恰恰相反:如果它顺利运行了,还会使测试变得更复杂,更难读懂。”

“但是我决定使用Mockito进行所有的测试!”

我: ”。。。。。。”

下一次我碰到他,他自豪地说,他已经设法用Mockito写了测试。我明白这个工作会让他的心里产生满足感,但是他的解决方法还是让我感到难过。

另一个例子

我被开发新应用程序的高代码覆盖率以及他们对BDD(行为驱动设计)的新发现所吸引。观察代码,我们发现以下Cucumber测试:

img

如果您以前使用过Cucumber测试 ,你就不会被支持代码的数量惊讶到:

img

img

并且所有这些都需要测试:

img

是的,这只是一个简单的map查找。我相信他,但还是直言不讳地说:“这是在浪费时间。”

“但我的老板希望我能为所有的类写测试,”他回答。

“代价是什么?”

“费用?”

“不管怎么说,这些测试与BDD无关。”

“我知道,但我们还是决定使用Cucumber进行所有测试。”

我: “。。。。。。”

我能理解按照自己的意志改造工具带来的满足感,但这种解决方案让我感到难过。

悲剧在哪里?

悲剧是,两位聪明的开发人员(我们都要接受一个 team interview)浪费时间写这些测试,测试是毫无意义的,但这需要后来的IG开发人员来维护。

悲剧是,不用使用正确的工具,因为没有什么好的理由,我们决定不要用错误的工具。

悲剧是,一旦“所谓的好的做法”成为公司开发主流,我们似乎就会忘了这种做法的应用场景,它的优点是什么,使用它的代价是什么。

相应的,如果我们只是机械地应用它,不去思考它的原理,这通常意味着我们最终得到最平庸的结果,并且失去大部分的开发优势,还要为此付出更大的代价。根据我的经验,写好的单元测试其实是项艰难的工作。

那么100%的代码覆盖率是值得追求的吗?

是的,每个人都应该在一个项目中实现。我认为你必须极端地去了解这么做带来的痛苦是什么。

我们已经有了一个极端的经验:开发有0个单元测试的项目,我们知道这样做所带来的痛苦。通常我们缺乏的是另一个极端的经验:开发100%代码覆盖率和一切都是TDD的项目。单元测试(特别是第一种方法)是一个非常好的做法,但我们应该分辨哪些测试是有用的,哪些是适得其反的。

但记住没有什么工具使用起来是毫无代价的,没有工具是万能的,使用前请停下来想一想。


SDCC 2017·深圳站之架构&大数据技术实战峰会将于2017年6月10-11日于深圳南山区中南海滨大酒店举行,集阿里、腾讯、百度、滴滴出行、Intel、微博、唯品会的资深架构师和一线实践者,纳知名研发案例,遇见苏宁云商大数据中心总监陈敏敏、Apache RocketMQ联合创始人冯嘉、饿了么大数据平台部总监毕洪宇等大牛。
目前八折优惠售票中,五人团购立减1000元,更多嘉宾和详细议题关注大会官网和票务点击注册参会

评论