100% 代码覆盖率的悲剧

本文最初发表于IG 博客

事情的反转真是有趣。十五年来，我一直在宣扬TDD，或者至少建议开发人员编写一些单元测试。然而，最近我发现自己越来越多地问自己：“你为什么要写那个测试？”，而不是“你应该写一个测试”。

到底是怎么回事？

我在办公室里走动时，一位开发人员请我帮他做一些单元测试。他似乎在使用 Mockito 测试以下代码时遇到了麻烦：

我想他对我的回答感到非常惊讶：“你不需要测试这个。”

“但我必须这么做！”他说，“那我怎么知道密码能不能用呢？！”

“代码很明显。没有条件，没有循环，没有转换，什么都没有。这段代码只是一些普通的胶水代码。”

“但是如果没有测试，任何人都可以来修改并破解密码！”

“你看，如果那个想象中的邪恶/无知的开发人员出现并破坏了那段简单的代码，你认为如果相关的单元测试失败他会怎么做？他只会删除它。”

“但如果你必须参加考试怎么办？”

“既然如此，我会这样测试：”

“但是你没有使用 Mockito！”

“那又怎样？Mockito 帮不了你。恰恰相反，它只会妨碍你，不会让测试更易读或更简单。”

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

我： ”…”

下次我碰到他时，他自豪地说他已经用 Mockito 写好了测试。我能理解测试成功后的那种满足感，但即便如此，我还是感到难过。

另一个例子

一位开发人员把我拉了进来，他对自己新应用的高代码覆盖率以及对BDD的新热爱感到非常兴奋。查看代码后，我们发现了以下Cucumber测试：

如果您以前使用过 Cucumber，那么您不会对它所需的支持代码的数量感到惊讶：

所有这些都需要测试：

是的，简单的地图查找。

我对开发人员有足够的信任，可以直截了当地说：“这太浪费时间了。”

“但是我的老板希望我为所有课程参加考试，”他回答道。

“以……为代价？”

“费用？”

“无论如何，这些测试与 BDD 无关。”

“我知道，但我们决定在所有测试中使用 Cucumber”

我： ”…”

我理解将工具按照自己的意愿使用所带来的精神满足，但尽管如此，它还是让我感到难过。

悲剧在哪里？

悲剧的是，两个聪明的开发人员（我都会带他们去团队面试）却在浪费时间编写这些毫无意义的测试，而这些测试需要由未来几代 IG 开发人员来维护。

悲剧的是，我们没有使用正确的工具来完成工作，而是决定继续使用错误的工具，没有任何特别好的理由。

悲剧的是，一旦一种“好的做法”成为主流，我们似乎就会忘记它是如何产生的，它的好处是什么，最重要的是，使用它的成本是多少。

相反，我们只是机械地套用，没有经过太多思考，这通常意味着我们最终得到的充其量只是平庸的结果，失去了大部分好处，却付出了全部（甚至更多）的代价。以我的经验来看，编写好的单元测试是一项艰苦的工作。

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

是的，每个人都应该在一个项目中实现它。我认为，你必须竭尽全力才能知道极限在哪里。

我们已经对一个极端的情况积累了丰富的经验：零单元测试的项目，所以我们深知处理这类项目的痛苦。我们通常缺乏的是另一个极端的情况：强制执行 100% 代码覆盖率且所有代码都采用 TDD 开发的项目。

单元测试（尤其是测试优先方法）是一种非常好的实践，但我们应该了解哪些测试是有用的，哪些测试是适得其反的。

但请记住，没有什么是免费的，没有什么是灵丹妙药。停下来思考一下。