测试驱动开发的操作非常简单。
1、编写测试代码
2、运行测试用例，发现用例不通过
3、增加少量实现代码
4、运行测试用例，用例通过
5、重构

其中有三个比较关键的因素：测试、节奏、驱动。

测试驱动开发首先要讲的就是测试了。以前在一个项目中，我需要写一个带有非常复杂业务的计算类。当时对于能否写出来完全没有信心，主要是情况太复杂，分支特别多。其中涉及到表达式的解析，自定义变量的引用关系，数据的汇总计算等。这时候如果采用传统的开发方式是很难保证代码的正确性，糟糕的情况就是在后台计算类中的Bug只有在界面部分才能测试出来。后来决定采用测试驱动开发的方式，先构造用例，然后写实现代码。一方面可以从用例的角度分析这个模块的功能，更重要的另外一个方面可以确保计算类的低Bug率。
在有了测试代码的基础上，在去实现这样的需求心里是更加有底气的。并且检查复杂的程序内部逻辑比检查一个个的测试用例要复杂得多。
重构是建立在拥有测试代码的基础上的。

节奏确定了效率。从上面介绍的测试驱动开发的五步中可以明确地看到一种节奏感。如果使用现在流行的测试框架，如：XUnit，在运行的时候可以看到“红绿交替”的现象。（红色代表用例未通过、绿色代表用例通过）。并且上面说的五步循环的时间非常短，往往以分钟为单位衡量。
有了一个好的节奏，可以有力地支撑结对编程的实践。
结对编程的概念很容易理解：两个人共用一台计算机编写代码。但实践的时候会遇到很多问题。
以前在做结对编程的时候出现两个人不“合拍”的情况。表现就是一个人在写代码，另外一个人在“思考”或者“发呆”。有的时候是觉得其中一个写代码写累了，再换成另外一个。或者总是一个人在写代码，另外一个在旁辅导。
TDD中有一个节奏的问题。一个任务被分解成“红条”、“绿条”的交替。结对的两个人注意力全部放在“红绿交替”上。这样可以确保两个人的步调一致，双方都知道现在我们做到了第几步。通常可以一个人编写测试用例，另外一个人实现，然后交换。
怎样编写让对方出错的用例，怎样不让自己的代码有漏洞。开发就在这种合作、竞争的互动游戏中进行。

体会到了测试与节奏带来的好处之后，最近发现TDD与简单设计也有着比较紧密的关系。
如果能真的做到“驱动”这个效果，不编写任何一行测试用例不需要的冗余代码，在没有用例证明的情况下不做结构上的设计。这样将未做的工作最大化的艺术就是简单设计的核心。
并不是说不需要设计，而是说设计的意图必须要有相应的用例证明。

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=752613