为什么我反对追求测试覆盖率?

发表于:2017-5-24 10:06

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:Aladdin    来源:极客头条

  有趣的是,我对测试的观点正在发生变化。十五年来,我一直在推广TDD(测试驱动开发,过去也被称为测试优先方式),或至少对于开发者来说,写一些单元测试。不过,最近我发现自己更常说:“你为什么要写测试?“而不是“你应该写测试”。
  到底是怎么回事?
  在办公室周围走走时,开发人员要求我帮助他进行单元测试。看来他在使用Mockito测试以下代码时遇到了麻烦:
  
  当我回应:“你不需要测试。”,他感到非常惊讶。
  “但我不得不测啊!”他说。“不测试我怎样知道这段代码能运行啊?”
  “这段代码的功能看起来很简单,没有条件,没有循环,没有转换,没有任何复杂的东西,只是一段简单的老胶水代码。
  “但不测试的话,任何人都可以来更改这段代码啊!”
  “好,那我们试想来了个无知的开发者,试图更改这些简单的代码,如果相关的单元测试发生了变化,他会做什么,他只会删除它。“
  “但是如果你非要写测试怎么办呢?”
  “在这种情况下,我会这样写测试:”
 
  “但是你没有使用Mockito啊!”
  “那又怎么样?Mockito在这种情况下不仅没有帮助,恰恰相反:如果它顺利运行了,还会使测试变得更复杂,更难读懂。”
  “但是我决定使用Mockito进行所有的测试!”
  我:”。。。。。。”
  下一次我碰到他,他自豪地说,他已经设法用Mockito写了测试。我明白这个工作会让他的心里产生满足感,但是他的解决方法还是让我感到难过。
  另一个例子
  我被开发新应用程序的高代码覆盖率以及他们对BDD(行为驱动设计)的新发现所吸引。观察代码,我们发现以下Cucumber测试:
  如果您以前使用过Cucumber测试,你就不会被支持代码的数量惊讶到:
  
  并且所有这些都需要测试:
  
  是的,这只是一个简单的map查找。我相信他,但还是直言不讳地说:“这是在浪费时间。”
  “但我的老板希望我能为所有的类写测试,”他回答。
  “代价是什么?”
  “费用?”
  “不管怎么说,这些测试与BDD无关。”
  “我知道,但我们还是决定使用Cucumber进行所有测试。”
  我:“。。。。。。”
  我能理解按照自己的意志改造工具带来的满足感,但这种解决方案让我感到难过。
  悲剧在哪里?
  悲剧是,两位聪明的开发人员(我们都要接受一个teaminterview)浪费时间写这些测试,测试是毫无意义的,但这需要后来的IG开发人员来维护。
  悲剧是,不用使用正确的工具,因为没有什么好的理由,我们决定不要用错误的工具。
  悲剧是,一旦“所谓的好的做法”成为公司开发主流,我们似乎就会忘了这种做法的应用场景,它的优点是什么,使用它的代价是什么。
  相应的,如果我们只是机械地应用它,不去思考它的原理,这通常意味着我们最终得到最平庸的结果,并且失去大部分的开发优势,还要为此付出更大的代价。根据我的经验,写好的单元测试其实是项艰难的工作。
  那么100%的代码覆盖率是值得追求的吗?
  是的,每个人都应该在一个项目中实现。我认为你必须极端地去了解这么做带来的痛苦是什么。
  我们已经有了一个极端的经验:开发有0个单元测试的项目,我们知道这样做所带来的痛苦。通常我们缺乏的是另一个极端的经验:开发100%代码覆盖率和一切都是TDD的项目。单元测试(特别是第一种方法)是一个非常好的做法,但我们应该分辨哪些测试是有用的,哪些是适得其反的。
  但记住没有什么工具使用起来是毫无代价的,没有工具是万能的,使用前请停下来想一想。
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号