您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件测试技术 > 单元测试 > 正文

写单元测试的12个好处

发表于:2017-01-09 作者:网络转载 来源:

  「写单元测试的好处是什么?」
  这个问题非常难以回答。通常只能得出「只有写了才知道」这种含糊不清的答案。
  我最近找到Tim King文章 ,非常完整的回答了这个问题。
  看过之后觉得获益良多,翻译出来和大家分享。
  为什么工程师会讨厌写单元测试?为什么他们会拒绝先写单元测试?不用解释了,那些接口我全听过。我知道真正的原因为何。
  大部份的工程师根本没认真试过测试先行。不然就是当下的环境不支持他们写,导致他们不知道自己在干嘛。前者的情况居多。最后他们就找接口:「我们没时间写单元测试」、「单元测试不能完全保证程序代码品质」。这是在替自己的窘境找理由,而不是真的觉得不写比较好。有趣的是,当这种人直接在你面前开发,你常会看到他开发得很不顺,进度常常在开倒车。目睹这种事满有趣的。但他依旧不会收回原本的看法、依旧不愿意先写测试。这种坚持根本有害。
  Kent Beck在《Test Driven Development By Example》书中提到,测试先行有3个步骤:
  1. Red :写个能表达你打算如何使用那段code的测试,还有你期待它做什么。这个测试会失败。很多界面会用红色信息来表示它。
  2. Green :写出足够的code来让那个测试成功,但别多写。如果你想写更多code,象是检查某些错误的话,那就先另写一个测试表达它。当下只要写刚好够的code去通过测试即可。
  3. Refactor :把多余的code清理一下,然后改善整体设计。之后再跑一次测试,确保没弄坏什么地方。
  重复这些步骤直到功能做完。这个流程超级简单。为什么工程师会畏惧它?因为这会逼他们从根本上改变开发习惯。
  我们认为自己在写code前不需要先去思考,这些code到底要做什么。
  你如何解决一个软件问题?学校是怎么教的呢?第一步怎么走?你大概只想着如何解决问题本身。你心想:「我要写哪些code来实现出解决方案?」其实你不应该先想「我要写哪些code」,你要先想「我要怎样才能确定问题已经被解决了?」
  我们直觉认为一段code的正确与否,只要执行一次就知道了,超明显的,何必写那种根本废话的测试?就是这种根深蒂固的想法,导致大部份的人改不了开发习惯。
  成功跨过那道鸿沟的人,可以感受到下列几项好处。我全部体会过。不用完全信我,你自己试试看就知道了。
  1. 单元测试保证你的code真的能动
  这会让bug减少。当然,单元测试不能取代系统测试和验收测试。但单元测试能补足他们的短处。
  2. 你会得到一组低层的regression-test suite
  这让你随时可以回头去检查有否哪些坏掉、bug在哪。很多团队会每天把整组测试跑一遍。这让你在把程序交给品管部门之前,可以很轻松的把bug抓出来。
  3. 让你改善系统设计的时候,不怕弄坏系统
  其实就是测试先行3步骤的第3步。通常测试先行写出来的code不太需要重构。我看过很多超糟糕的系统,就像精神病患一样,根本无法搞定。如果有准备好单元测试,你就可以对系统里面最难搞的部份做出有效的重构。
  4. 写测试会让coding更好玩
  你会先搞懂自己的code要做什么。然后再让它完成任务。就算系统还没全做完,你还是能看到code真的动起来,而且真的没出错。你会得到一种「我完成了!」的感觉。每分钟都会不断感受到喔。只要试试测试先行,你就会整个人high起来、对自己的作品感到骄傲、被激励去完成更多事情。
  5. 它们可靠地展现目前进度
  你不用为了等整个系统组装起来而多等一个月。在系统完成之前你就能展示进度了。不但能说自己写了code,还能真的跑给别人看。传统开发有件事搞错了。「完成」不等于你写了code然后丢出去。「完成」应该是你的code能在系统里跑,而且没bug。写测试会让你更接近这点。
  6. 单元测试是一种使用范例
  我们都碰过那种不知道怎么用的library。通常我们会先去找范例程序码。使用范例可算是一种文件。但公司内部的code通常不会有范例可看。所以只好慢慢试、在系统内东找西找了。因为那个同事可能根本离职了,想问他都没办法。单元测试可以当作一种文件。当你不知道Foo类别怎么用,去看一下单元测试怎么写的即可。
  7. 测试先行会强迫你写code前先做规划
  先写测试会逼你在动手开发前把必须完成的事和整体设计想过一遍。不但让你更专注,还能让设计更漂亮。
  8. 先写测试能减少bug的成本
  越早发现bug越容易修。之后出现的bug通常是改了好几个地方才出现的,
  导致很难抓出哪里导致了bug。一开始先找出bug在哪,然后要重新回想这段code是怎么写的,因为可能是几个月前写的。最后才终于弄懂,搞出一套解法。只要能减少抓bug以及修好bug的时间,几乎都算大赚。如果在成品交给品管部门或是顾客之前,我们只花几天就找出bug,通常算是很幸运。那几花几分钟就找出bug呢?测试先行就能做到这点。
  9. 它比代码检查的效果好
  有人说事前代码检查比事后测试系统更好,因为成本比较低。在系统完成之后才测试系统,要修好bug可说是麻烦多了。越早发现bug,就越简单、越便宜、越好搞定。代码检查的好处就在这:只花几天就能抓出bug,不需要等几个月。但是测试先行成本更低。只要几分钟就抓出bug,连几天都不用。
  10. 几乎解决了「开发者瓶颈」(coder’s block)
  不知道下一行写什么吗?就跟「作家瓶颈」(writer’s block)一样,开发者瓶颈很可能是个大问题。测试先行有系统地处理开发上关于结构的部份,让你能专心在需要创造的部份。你可能会卡在下段code不知道怎么测、该怎么通过测试,但你永远不会因为下一步卡住。通常会有完全相反的结果:你很想在累倒之前休息一下,但因为清楚看到前面的录了,所以根本不想停下来。
  11. 单元测试让设计更棒
  测试一小块code会强迫你定义清楚那段code负责什么。如果测起来很简单,就表示它的责任很明确,cohesion很高。如果一段code能被单元测试,那就表示它很容易就能放进系统之中,就跟它很容易放进测试之中一样。它跟相关的code只具有loose coupling 。 High cohesion与loose coupling代表了出色、好维护的设计。容易测试的code也很容易维护。
  12. 写测试会让开发速度更快
  不写单元测试也许会让速度更快,但无法保证code真的能跑。开发上会花一堆时间在在事后的修bug。测试先行会消除这类的浪费,从一开始就做对、让bug更好修。
  就算好处这么多,很多工程师还是继续维持他们的老样子。如果你在组织里极度重视流程,你跟他们一部份人会起冲突。我只能祝你好运。记住一件事,人们不会因为一个东西听起来不错就买帐。他们只有在极度渴望、超想得到手来品尝时才会买帐。希望以上几点可以帮助你说服他们。
  不过,如果你是前者,也就是那种顽固的工程师,不在乎好的软件设计,只在乎坚持己见…。嗯,我觉得你还真可怜。