100％代码覆盖率的悲剧

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

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

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

到底是怎么回事？

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

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

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

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

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

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

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

“在这种情况下，我会这样写测试：”

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

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

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

我： ”。。。。。。”

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

另一个例子

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

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

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

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

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

“代价是什么？”

“费用？”

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

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

我： “。。。。。。”

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

悲剧在哪里？

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

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

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

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

那么100％的代码覆盖率是值得追求的吗？

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

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

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

---

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