测试驱动开发——我们要的不仅仅是“质量”转51testing

测试驱动开发

测试驱动开发，英文全称Test-Driven Development，简称TDD，是一种不同于传统软件开发流程的新型的开发方法。它要求在编写某个功能的代码之前先编写测试代码，然后只编写使测试通过的功能代码，通过测试来推动整个开发的进行。这有助于编写简洁可用和高质量的代码，并加速开发过程。

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

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

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

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

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

　　测试驱动开发环

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

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

　　编写测试时我就仅仅关注测试，我不想去如何实现，我只想我要什么（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是可以独立编写功能测试的）编写出该用户故事如果要验收的话需要通过的功能测试。这是测试驱动开发的外层反馈环，然后使用单元测试驱动功能代码，这是内层反馈环（反馈是极限编程四个准则之一，这四个准则是沟通、反馈、简单、勇气）。我们就是通过不断的向前探索，不断的收到反馈来稳妥的完成我们的任务的，我们的信心也在不断地增强，进度也在不断地推进。

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

　　绝不跳过重构

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

　　尽快变绿

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

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

　　出错后放慢脚步

　　后记

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