BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 丁雪丰 关注 3 他的粉丝 发布于 2012年2月27日. 估计阅读时间: 4 分钟 | GMTC大前端的下一站,PWA、Web框架、Node等最新最热的大前端话题邀你一起共同探讨。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

代码的可测试性直接关系到进行单元测试顺利与否! by 高 翌翔

文中已说得很明白了,代码的可测试性低劣是导致单元测试举步维艰的直接原因!

而代码的可测试性低与架构设计及详细设计直接相关,
因此必须努力提升架构师和开发者设计能力,才有可能使单元测试走出困境!

这文章是出自实战者之手 by 陈 国栋

确是好文章,道出了真正开发环境下的种种困境,并提出解决问题的思路。感谢作者,让我感到自己并不孤单!

很好 by song zhang

"通过结对编程可以减少低质量的单元测试,人都喜欢改变,但没人喜欢被改变,不要强求结对编程,让他看到好处,尝到甜头,吸引他来做结对编程,没有人喜欢落后,比如50%的人在做结对了,剩下的人自然会想尝试。"

以上这句很好。

说实话,我很不喜欢“根据XXX原则” by bao wenle

虽然本文中没什么问题。
实践大于理论
独立思考

Re: 这文章是出自实战者之手 by 东喆 王

说的借口都很实际,我周围都遇到过这些问题。覆盖率的观点很赞同,覆盖逻辑胜于覆盖代码行数。

搞清楚到底想测什么 by 张 凯峰

搞清楚了,依赖自然需要理清,复杂逻辑就会被切分到更小的方法

可测试的代码 by 雷 慈祥

只有设计简单的代码,才易于测试,才方便测试,反过来测试也会给你让你尝试去改进你的设计的勇气。

设计可测试的代码 by 林 足雄

好文章!

如何进行单元测试 by Wong Peter

根据二八原则,直接寻找代码库里最常被修改的文件,一般的文件只有几次修改,有的文件则被修改了几十次,为它增加测试。

如果单元测试实施成本很高,可以先加功能测试。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

9 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT