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

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

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

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

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

　　绝不跳过重构

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

　　尽快变绿

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

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

　　出错后放慢脚步

　　后记

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