100％代码覆盖率的悲剧

作者介绍

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

十五年来，我一直在推广TDD（测试驱动开发），或让开发写一些单元测试。不过，最近我发现自己对于测试的想法开始改变，现在我更经常说的是：“这段代码（模块）为什么要进行测试？“而不是“这段代码应该进行测试”。

背景

有一天，一位开发人员找我帮忙，他在进行单元测试时，确切的说是他在使用Mockito测试以下代码时遇到了麻烦：

当我跟他说：“这里不需要测试。”，他感到非常惊讶。

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

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

“但任何人都可能会来更改这段代码啊，若不测试怎么能知道这段代码有没有被动过！”

“好，那我们假设有人想改动这段代码，他会做什么？他只会删除它。“

“但是如果必须要进行测试，你怎么写？”

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

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

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

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

我： ”……”

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

另一个例子

有一个应用程序，覆盖率非常高（开发模式为BDD—“”行为驱动设计”），这引起了我的注意。通过观察代码，我发现以下Cucumber测试：

如果您以前使用过Cucumber测试 ，你就不会对如何多的支持代码感到惊讶了：

所有这些都需要测试：

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

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

“代价是什么？”

“费用？”

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

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

我： “……”

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

悲剧在哪里？

悲剧是，两位开发人员耗费时间写的这些测试，是毫无意义的，并且还需要不断投入人力来维护。

悲剧是，有些场景明明有更好的测试工具，却不去采用。

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

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

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

我认为，我们有必要去了解这么做所带来的代价是什么。

我们都有这样的常识：项目完全不做单元测试，后果会非常让人痛苦。但我们很少人意识到另一个极端会带来什么问题：即达到100％代码覆盖率或者一切项目都是TDD模式开发。单元测试是一个非常好的做法，但我们应该分辨哪些测试是有用的，哪些是适得其反的。

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

文章作者 | Daniel Lebrero

翻 译 | Mack