内容简介：为什么我反对追求测试覆盖率
有趣的是，我对测试的观点正在发生变化。十五年来，我一直在推广TDD（测试驱动开发，过去也被称为测试优先方式），或至少对于开发者来说，写一些单元测试。不过，最近我发现自己更常说：“你为什么要写测试？“而不是“你应该写测试”。
到底是怎么回事？
在办公室周围走走时，开发人员要求我帮助他进行单元测试。看来他在使用Mockito测试以下代码时遇到了麻烦：
当我回应：“你不需要测试。”，他感到非常惊讶。
“但我不得不测啊！” 他说。“不测试我怎样知道这段代码能运行啊？”
“这段代码的功能看起来很简单，没有条件，没有循环，没有转换，没有任何复杂的东西，只是一段简单的老胶水代码。
“但不测试的话，任何人都可以来更改这段代码啊！”
“好，那我们试想来了个无知的开发者，试图更改这些简单的代码，如果相关的单元测试发生了变化，他会做什么，他只会删除它。“
“但是如果你非要写测试怎么办呢？”
“在这种情况下，我会这样写测试：”
“但是你没有使用Mockito啊！”
“那又怎么样？Mockito在这种情况下不仅没有帮助，恰恰相反：如果它顺利运行了，还会使测试变得更复杂，更难读懂。”
“但是我决定使用Mockito进行所有的测试！”
我： ”。。。。。。”
下一次我碰到他，他自豪地说，他已经设法用Mockito写了测试。我明白这个工作会让他的心里产生满足感，但是他的解决方法还是让我感到难过。
另一个例子
我被开发新应用程序的高代码覆盖率以及他们对BDD（行为驱动设计）的新发现所吸引。观察代码，我们发现以下Cucumber测试：
如果您以前使用过Cucumber测试 ，你就不会被支持代码的数量惊讶到：
并且所有这些都需要测试：
是的，这只是一个简单的map查找。我相信他，但还是直言不讳地说：“这是在浪费时间。”
“但我的老板希望我能为所有的类写测试，”他回答。
“代价是什么？”
“费用？”
“不管怎么说，这些测试与BDD无关。”
“我知道，但我们还是决定使用Cucumber进行所有测试。”
我： “。。。。。。”
我能理解按照自己的意志改造 工具 带来的满足感，但这种解决方案让我感到难过。
悲剧在哪里？
悲剧是，两位聪明的开发人员（我们都要接受一个 team interview ）浪费时间写这些测试，测试是毫无意义的，但这需要后来的IG开发人员来维护。
悲剧是，不用使用正确的工具，因为没有什么好的理由，我们决定不要用错误的工具。
悲剧是，一旦“所谓的好的做法”成为公司开发主流，我们似乎就会忘了这种做法的应用场景，它的优点是什么，使用它的代价是什么。
相应的，如果我们只是机械地应用它，不去思考它的原理，这通常意味着我们最终得到最平庸的结果，并且失去大部分的开发优势，还要为此付出更大的代价。根据我的经验，写好的单元测试其实是项艰难的工作。
那么100％的代码覆盖率是值得追求的吗？
是的，每个人都应该在一个项目中实现。我认为你必须极端地去了解这么做带来的痛苦是什么。
我们已经有了一个极端的经验：开发有0个单元测试的项目，我们知道这样做所带来的痛苦。通常我们缺乏的是另一个极端的经验：开发100％代码覆盖率和一切都是TDD的项目。单元测试（特别是第一种方法）是一个非常好的做法，但我们应该分辨哪些测试是有用的，哪些是适得其反的。
但记住没有什么工具使用起来是毫无代价的，没有工具是万能的，使用前请停下来想一想。
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
Pro JavaScript Techniques
John Resig / Apress / 2006-12-13 / USD 44.99
Pro JavaScript Techniques is the ultimate JavaScript book for the modern web developer. It provides everything you need to know about modern JavaScript, and shows what JavaScript can do for your web s......一起来看看 《Pro JavaScript Techniques》 这本书的介绍吧!
