代码改变世界

测试驱动开发(一)-我们要的不仅仅是“质量”

2011-01-05 22:45 by 横刀天笑, ... 阅读, ... 评论, 收藏, 编辑

《敏捷软件开发实践》之测试驱动开发

测试驱动开发是极限编程里很重要的一个实践,很多其他实践都是以这个实践为基础的。

测试驱动开发核心就是所有的实现都是测试“逼”出来的,所有的实现代码都是为了让测试通过而编写的,如果测试都通过了我们就可以拒绝再添加新的功能了或新的代码了,要让我写更多的代码,好,添加一个测试吧。

测试驱动开发的道理很简单:要知道好坏,用用才知道。比如,你想要买个东西,你肯定最想知道的是使用过这个东西人的评价,因为没有使用这个东西很难知道这个东西是不是好的。软件和代码也是一样,你设计一块代码为的是什么,为的是别的代码可以调用这块代码干一些事情,那怎么才能知道你写的代码是不是好的呢。那么测试驱动开发就是,我先以调用方的角度来调用这块代码,并且从调用方的角度说出我期望的结果。在这里我们不仅仅对期望的结果进行验证,很重要的一点是,我们先用用你这个接口,好不好用。一般来讲如果你的代码依赖很多其他元素,那么将是很难测试的,因为在单元测试中你必须解除对其他元素的依赖,所以使用测试驱动开发出来的代码,往往具有很好的低耦合性。

当我们写单元测试时,我们往往在一个测试里只测试“目的”,如果你发现你的测试方法名称里总是带有and/or之类的单词时,这就表明被测试的方法职责可能不单一,这也有助于帮助我们找出职责不单一的代码。

单元测试一个最重要的作用估计就是设置安全网,将你的代码放置在这个网中,当以后需要改进代码的时候可以快速的自动化回归以前所有的测试,以保证你改进代码的时候没有破坏以前的功能。但人都是懒惰的,如果是先写功能实现代码,后写测试,有的时候我们就得过且过算了,因为觉得那测试实在太简单了,而且有时候因为功能代码写得不好,造成后面很难添加测试,然后懒惰心理作怪,得过且过,就把测试给跳过去了。如果我们确定一个规则:没有测试失败我拒绝写代码,那么在你写功能代码的时候这张安全网就已经设置好了。后面所有的任何代码都是为了修复失败的测试。而且看见绿条一次又一次的亮起,总是给我们无比的信心,一个接一个的测试通过了,就是告诉我们正在稳步前进,我们离成功又接近了一步。

测试驱动开发环

下面是经典的测试驱动环:

image

我们先写一个失败的测试(实际上第一个测试可能编译都无法通过),然后编写很少的代码让测试迅速通过,然后我们看看代码是不是需要重构,在这里我们不仅仅需要重构功能代码,测试代码也需要重构。然后我们接着编写下一个测试,这个循环将不断的推动下去。

编写测试时我就仅仅关注测试,我不想去如何实现,我只想我要什么(what),至于怎么做(how)是下一个环节要考虑的。这样有什么好处呢?首先,这样可以避免测试被实现牵着鼻子走,以前为什么反对程序员自己给自己的软件写测试,就因为实现是他写的,他可能因为定性思维自动的而且无意识的绕过了一些陷阱,所以在测试驱动开发的时候,有的人常常出现这种情况:键盘上敲的是测试代码,但大脑中全部是实现。所以在上一篇谈论结对编程的文章中,有一种结对编程就是一个人写测试,另外一个人写实现就是为了避免这种情况。

拿个最简单的例子来说,如果你用MVC来开发一个web,你要写一个action方法,那么你想要什么?第一个:也许是视图的名字,第二个:也许是要put到视图中的模型数据。好,那我们就验证这个:

   1: ModelAndView mv = bookController.show(bookId);
   2: assertThat(mv.getViewName(),is("book"));
   3: assertThat(mv.getModel().get("book"),is(book));

嗯,我开始就写出上面的代码,这是我想要的,至于怎么实现那是后面的事情,我在这儿并不关心。在这里也说明了一种测试驱动开发时候的技巧:因为测试时我们需要先准备数据,准备设施,因为这个时候功能实现代码还不存在,有可能我们很难写出测试代码,所以往往碰到无从下手的情况,对于这种情况,我们会先写出assert语句,我们把我们想要的东西先放在这儿,然后往反向推导,毕竟不管怎样我们想要什么,我们还是知道滴。

在编写实现的时候要主意的是千万不要过度,我们编写刚刚好的代码,让我们失败的那个测试通过就好了,不需要你一气呵成,写一大堆代码出来。因为你写实现代码的时候总是在假想你所写的代码是真实的实现,但往往这会走向过度设计。关注现在是避免过度设计最好的良药。

在测试通过后,千万别忘记了重构代码,因为之前的环节我们总是在关注与当前的一小块范围,可能产生了很多重复的代码,或者变量命名都是草草了事,这个时候更应该从更高的视角来审视刚才的代码,做有必要的重构,然后编写下一个测试。

大部分测试驱动开发说的都是使用单元测试然后驱动出功能代码,实际上测试驱动开发可以上升到更高的层次,从功能测试开始。往往一个用户故事来了,QA(知道有哪些测试用例)和开发人员结对(当然,有些QA是可以独立编写功能测试的)编写出该用户故事如果要验收的话需要通过的功能测试。这是测试驱动开发的外层反馈环,然后使用单元测试驱动功能代码,这是内层反馈环(反馈是极限编程四个准则之一,这四个准则是沟通、反馈、简单、勇气)。我们就是通过不断的向前探索,不断的收到反馈来稳妥的完成我们的任务的,我们的信心也在不断地增强,进度也在不断地推进。

在《测试驱动开发艺术》这本书里提到,测试驱动开发应该遵守三项基本原则:

绝不跳过重构

不跳过重构,保证我们的代码质量不走向腐化,在这个时候我们不仅仅只重构我们的功能代码,对测试代码也要公平对待,随着我们测试代码的不断加入,肯定有重复的地方可以提取,这些都要重构,保持测试代码整洁对以后的重构工作非常重要。

尽快变绿

反馈是极限编程四个基本原则之一(其他三个是:沟通、简单、勇气),运行测试的一个作用就是能快速地提供反馈。运行一下测试,测试就会告诉你,你刚才的那一步走的怎样。保证每踏出一脚都是稳稳当当的很重要,不仅能建立起信心,而且如果某一步失败了,我们可以立马确定是哪里出错了。

有些开发人员习惯一下子写出四五个测试,然后再去实现,他们还争辩说,我很清楚需要这么几个测试用例,我何必要在测试代码和功能实现代码之间跳来跳去呢。首先不说你是不是能一下子想清楚这些测试用例。再次,写出太多的测试,可能让这些测试编译通过就要费一番周折(因为功能代码还不存在,可能有的类和方法都不存在),然后还要费更多的功夫让这所有的测试通过,那么你停留在红的阶段就太久了,不利于给自己打气事关事小,步骤迈得太大,最后跌倒了会更痛。

出错后放慢脚步

 

后记

测试驱动开发是敏捷实践中一个非常重要的话题,本篇从理论上稍稍触及了一下测试驱动开发的一些原则,下篇会从代码上说明一些具体的测试驱动开发中的惯用法。

 

推荐书籍

《测试驱动开发的艺术》 我为这本书写了个书评

《测试驱动的面向对象软件开发》
《Test-Driven Development by Example》

《xUnit Patterns》