我讨厌单元测试:滕振宇谈如何进行单元测试

标签: 单元测试 何进 单元测试 | 发表时间:2012-02-26 14:09 | 作者:
出处:http://pipes.yahoo.com/pipes/pipe.info?_id=10560380f804c7341f042a2b8a03e117

说起单元测试的好处相信大家都能列举出不少,可是很多时候,开发人员面对自己产品的代码,想写单元测试却无从下手,久而久之,便会有人大喊:“我讨厌单元测试。”资深敏捷咨询师 腾振宇(Daniel Teng)在 GTUG-TopGeek开发工程管理沙龙就以此为题,结合最近的一个项目,和大家分享了他对单元测试的一些看法。

Daniel先介绍了下最近的一个项目,虽然不是遗留系统,但代码已经惨不忍睹,而且缺乏必要的测试保障,要修改代码可谓举步维艰。例如,一段代码和结对伙伴读了半小时没读懂,找来原作者看着注释又想了10分钟,终于才搞明白这段代码是做什么的。根据 二八原则,先找到那20%的点,修改它带来80%的价值。最直接的做法就是寻找代码库里最常被修改的文件,一般的文件只有几次修改,有的文件则被修改了几十次,每个人都在往复杂的代码里加入新的东西,但没有人往里面加测试,于是第一步就是为它增加测试。

很多开发者会说老项目就算了,如果新启动一个项目,我就会写单元测试了,Daniel认为这是一个“美好的梦想”,很多原因会打破它:

  • 代码已经很烂了,又没办法下手了
  • UI不好测
  • 认为这是QA的工作
  • 写的单元测试找不到Bug
  • 代码的外部依赖太多
  • 代码稍作修改,测试也要一并修改,太麻烦了

究其根本原因,是开发者根本不会写单元测试!满足什么标准的测试才是单元测试呢?根据 《修改代码的艺术》,需要访问数据库的测试 不是单元测试,需要访问网络的测试 不是单元测试,需要访问文件系统的测试 不是单元测试……

为了更方便地进行单元测试,业务代码应避免以下情况:

  • 存在太多条件逻辑
  • 构造函数中做的事情太多
  • 存在太多全局状态
  • 混杂了太多无关的逻辑
  • 存在太多静态方法
  • 存在过多外部依赖

例如,在代码中存在硬编码,或者是直接创建了一个数据库连接,这种做法都是比较危险的,因为在测试时没有办法“偷梁换柱”。

想要写好单元测试,学会重构是很重要的,重构的过程类似于清理厨房,虽然和做饭没太大关系,但可以让您下次做饭更方便,心情更好。可以重构的地方包括,在待测试类与其依赖之间增加一层Test Fixture;将创建逻辑与业务逻辑分开等等。重构可以采取以下策略:

  • 编写测试代码建立基本的防护网。在单元测试和功能测试之间要有取舍,如果单元测试实施成本很高,可以先加功能测试。
  • 通过增加中间层来打破依赖,不是为了去掉依赖,而是为了后续的修改以及测试的便利。
  • 将第一步中编写的功能测试换成单元测试。

最后,Daniel还为大家提了一些建议:

  • 项目里的 破窗要修好,别容忍别人加新的破窗,用测试将破窗保护起来。
  • 当你离开一个地方的时候,要让它比你来的时候更整洁干净。(童子军军规)
  • 不停地重构你的代码,每次走一小步。

随后有人提问,如何评估一个单元测试的质量,用代码行覆盖率是否可行。Daniel认为没必要去追求代码行覆盖率,真正要覆盖的是逻辑,而不是代码行。通过结对编程可以减少低质量的单元测试,人都喜欢改变,但没人喜欢被改变,不要强求结对编程,让他看到好处,尝到甜头,吸引他来做结对编程,没有人喜欢落后,比如50%的人在做结对了,剩下的人自然会想尝试。

当被问及单元测试是否是必须的时候,Daniel回答这并不是必要的,而是需要进行综合的衡量,比如你的竞争对手一周前推出了一个产品,你需要在一周内完成产品研发并上线,这时可以选择写或者不写单元测试,对于没有写过单元测试的人,一开始是需要上手的成本的。

如果您也对单元测试的话题感兴趣,不妨关注腾振宇的 博客微博,也可以观看 会议视频

丁雪丰 是InfoQ中文站编辑,满江红翻译组核心成员,出版过《Spring攻略》、《JRuby实战》等多部译著。主要关注领域:企业级应用、海量数据计算、动态语言应用等。

相关 [单元测试 何进 单元测试] 推荐:

我讨厌单元测试:滕振宇谈如何进行单元测试

- - InfoQ cn
说起单元测试的好处相信大家都能列举出不少,可是很多时候,开发人员面对自己产品的代码,想写单元测试却无从下手,久而久之,便会有人大喊:“我讨厌单元测试. ”资深敏捷咨询师 腾振宇(Daniel Teng)在 GTUG-TopGeek开发工程管理沙龙就以此为题,结合最近的一个项目,和大家分享了他对单元测试的一些看法.

Android单元测试

- - CSDN博客推荐文章
    单元测试不管对于初学编程还是已经工作了很久的开发者来说,都不乐意花时间去写认为没用的代码进行测试,只要交给测试人员就行了,虽然这样也能把软件改出来,但也许你要花上几倍的时间去修改问题,如果在开发的过程中花点时间去写单元测试代码,把尽可能出问题的地方都测试一遍,把问题扼杀在最开始的地方,这样你就不必为后来找问题出处而烦恼.

Hadoop之MapReduce单元测试

- - ITeye博客
通常情况下,我们需要用小数据集来单元测试我们写好的map函数和reduce函数. 而一般我们可以使用Mockito框架来模拟OutputCollector对象(Hadoop版本号小于0.20.0)和Context对象(大于等于0.20.0). 下面是一个简单的WordCount例子:(使用的是新API).

springboot单元测试技术

- - 海思
整个软件交付过程中,单元测试阶段是一个能够最早发现问题,并且可以重复回归问题的阶段,在单元测试阶段做的测试越充分,软件质量就越能得到保证. 具体的代码参照 示例项目 https://github.com/qihaiyan/springcamp/tree/master/spring-unit-test.

“单元测试要做多细?”

- - 酷壳 - CoolShell.cn
这篇文章主要来源是StackOverflow上的一个回答——“ How deep are your unit tests?”. 一个有13.8K的分的人( John Nolan)问了个关于TDD的问题,他说——. “TDD需要花时间写测试,而我们一般多少会写一些代码,而第一个测试是测试我的构造函数有没有把这个类的变量都设置对了,这会不会太过分了.

文章: Android中的单元测试

- - InfoQ cn
随着Agile的普及,以及开发人员对测试重要性的认识逐步加深,单元测试已经成了越来越多软件项目开发中不可缺少的一部分. 无论项目是不是采用TDD的形式来进行开发,单元测试都能够为项目的修改和重构提供一定的保障. 有奖参与:天翼伦敦会,上传应用,为中国队加油. QClub七月技术沙龙(太原/北京/上海/厦门/西安 7月21/28/29日 免费报名中.

迈出单元测试的第一步

- - 酷勤网-挖经验 [expanded by feedex.net]
单元测试不仅是软件行业的最佳实践,在敏捷方法的推动下,它也成为了可持续软件生产的支柱. 年度敏捷调查,70%的参与者会对他们的代码进行单元测试. 单元测试和其他敏捷实践密切相关,所以开始编写测试是组织向敏捷转型的踏脚石. 我将在本文介绍符合要求的小技巧,以及在开发周期里进行单元测试的步骤. 没有自动化,单元测试的习惯也不会持续太久.

iOS开发进阶之单元测试

- - 博客园_首页
本文侧重讲述如何在iOS程序的开发过程中使用单元测试. 使用Xcode自带的OCUnit作为测试框架. 单元测试作为敏捷开发实践的组成之一,其目的是提高软件开发的效率,维持代码的健康性. 其目标是证明软件能够正常运行,而不是发现bug(发现bug这一目的与开发成本是正相关的,虽然发现bug是保证软件质量的一种手段,但是很显然这与降低软件开发成本这一目的背道而驰).

Java 单元测试利器之 Junit

- - 博客园_首页
          因为工作和学习的需要,在代码中查错的时候,第一步就是想知道这个错误具体发生在一个位置,进行一个准确的定位. 而这个定位的工作交给谁来做了呢. 不难猜出也就是这篇博客的主题---Junit. junit是一个开源的框架,也是java这一块的测试工具之一. 想了解详细请上官网,下面用代码来跟大家解释.

单元测试里的 5 个错误

- - ITeye博客
当我第一次听说可以使用框架比如JUnit来进行单元测试的时候,我惊叹这真是一个简单而强大的概念. 它取代了随机测试,使你可以保存你的测试代码,并按照需要随时运行它们. 按照我的理解,关于单元测试并没有多少产生误解的可能. 但是过去的几年中,我确实见过几种或多或少不太正确的单元测试使用方式. 如果跟协作逻辑代码分离开来,那么算法逻辑是最容易测试的.