为什么我反对追求测试覆盖率
有趣的是，我对测试的观点正在发生变化。十五年来，我一直在推广TDD（测试驱动开发，过去也被称为测试优先方式），或至少对于开发者来说，写一些单元测试。不过，最近我发现自己更常说：“你为什么要写测试？“而不是“你应该写测试”。
到底是怎么回事？
在办公室周围走走时，开发人员要求我帮助他进行单元测试。看来他在使用Mockito测试以下代码时遇到了麻烦：
当我回应：“你不需要测试。”，他感到非常惊讶。
“但我不得不测啊！” 他说。“不测试我怎样知道这段代码能运行啊？”
“这段代码的功能看起来很简单，没有条件，没有循环，没有转换，没有任何复杂的东西，只是一段简单的老胶水代码。
“但不测试的话，任何人都可以来更改这段代码啊！”
“好，那我们试想来了个无知的开发者，试图更改这些简单的代码，如果相关的单元测试发生了变化，他会做什么，他只会删除它。“
“但是如果你非要写测试怎么办呢？”
“在这种情况下，我会这样写测试：”
“但是你没有使用Mockito啊！”
“那又怎么样？Mockito在这种情况下不仅没有帮助，恰恰相反：如果它顺利运行了，还会使测试变得更复杂，更难读懂。”
“但是我决定使用Mockito进行所有的测试！”
我： ”。。。。。。”
下一次我碰到他，他自豪地说，他已经设法用Mockito写了测试。我明白这个工作会让他的心里产生满足感，但是他的解决方法还是让我感到难过。
另一个例子
我被开发新应用程序的高代码覆盖率以及他们对BDD（行为驱动设计）的新发现所吸引。观察代码，我们发现以下Cucumber测试：
如果您以前使用过Cucumber测试 ，你就不会被支持代码的数量惊讶到：
并且所有这些都需要测试：
是的，这只是一个简单的map查找。我相信他，但还是直言不讳地说：“这是在浪费时间。”
“但我的老板希望我能为所有的类写测试，”他回答。
“代价是什么？”
“费用？”
“不管怎么说，这些测试与BDD无关。”
“我知道，但我们还是决定使用Cucumber进行所有测试。”
我： “。。。。。。”
我能理解按照自己的意志改造工具带来的满足感，但这种解决方案让我感到难过。
悲剧在哪里？
悲剧是，两位聪明的开发人员（我们都要接受一个 team interview）浪费时间写这些测试，测试是毫无意义的，但这需要后来的IG开发人员来维护。
悲剧是，不用使用正确的工具，因为没有什么好的理由，我们决定不要用错误的工具。
悲剧是，一旦“所谓的好的做法”成为公司开发主流，我们似乎就会忘了这种做法的应用场景，它的优点是什么，使用它的代价是什么。
相应的，如果我们只是机械地应用它，不去思考它的原理，这通常意味着我们最终得到最平庸的结果，并且失去大部分的开发优势，还要为此付出更大的代价。根据我的经验，写好的单元测试其实是项艰难的工作。
那么100％的代码覆盖率是值得追求的吗？
是的，每个人都应该在一个项目中实现。我认为你必须极端地去了解这么做带来的痛苦是什么。
我们已经有了一个极端的经验：开发有0个单元测试的项目，我们知道这样做所带来的痛苦。通常我们缺乏的是另一个极端的经验：开发100％代码覆盖率和一切都是TDD的项目。单元测试（特别是第一种方法）是一个非常好的做法，但我们应该分辨哪些测试是有用的，哪些是适得其反的。
但记住没有什么工具使用起来是毫无代价的，没有工具是万能的，使用前请停下来想一想。
本文文字及图片出自 CSDN
你也许感兴趣的：
- 都100%代码覆盖了，还会有什么问题？
- 代码覆盖率测试：从误传到现实
- 【外评】电脑从哪里获取时间？
- 【外评】为什么 Stack Overflow 正在消失？
- Android 全力押注 Rust，Linux 却在原地踏步？谷歌：用 Rust 重写固件太简单了！
- 【外评】哪些开源项目被广泛使用，但仅由少数人维护？
- 【外评】好的重构与不好的重构
- C 语言老将从中作梗，Rust for Linux 项目内讧升级！核心维护者愤然离职：不受尊重、热情被消耗光
- 【外评】代码审查反模式
- 我受够了维护 AI 生成的代码
你对本文的反应是：