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

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

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

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

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

　　测试驱动开发环

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

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

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

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