（Test Driven Development,英文缩写TDD）是极限编程的一个重要组成部分，它的基本思想就是在开发功能代码之前，先编写测试代码。也就是说在明确要开发某个功能后，首先思考如何对这个功能进行测试，并完成测试代码的编写，然后编写相关的代码满足这些。然后循环进行添加其他功能，直到完成全部功能的开发。代码整洁可用(clean code that works) 是测试驱动开发所追求的目标。

测试驱动开发有很多优点： 

(1)完工时完工。表明开发人员可以很清楚的看到自己的这段工作已经结束了，而传统的方式很难知道什么时候编码工作结束了。  (2)全面正确的认识代码和利用代码，而传统的方式没有这个机会。  (3)开发小组间降低了交流，提高了相互信赖程度。  (4)避免了过渡设计。  (5)系统可以与详尽的测试集一起发布，从而对程序的将来版本的修改和扩展提供方便。  (6)逃避了设计角色。对于一个敏捷的开发小组，每个人都在做设计。  (7)大部分时间代码处在高质量状态，100％的时间里成果是可见的。  (8)由于可以保证编写测试和编写代码的是相同的，降低了理解代码所花费的成本。  (9)为减少文档和代码之间存在的细微的差别和由这种差别所引入的作出杰出贡献。  (10)在预先设计和紧急设计之间建立一种平衡点，区分哪些设计该事先做、哪些设计该迭代时做提供了一个可靠的判断依据。  (12)发现比传统测试方式更多的Bug。

负面评价

1. 开发者可能只完成满足了测试的代码，而忽略了对实际需求的实现。有实践者认为用结对编程的方式可以有效的避免这个问题。
2. 会放慢开发实际代码的速度，特别对于要求开发速度的原型开发造成不利。这里需要考虑开发速度需要包含功能和品质两个方面，单纯的代码速度可能不能完全代表开发速度。
3. 对于GUI,资料库和Web应用而言。构造单元测试比较困难，如果强行构造单元测试，反而给维护带来额外的工作量。有开发者认为这个是由于设计方法，而不是开发方法造成的困难。
4. 使得开发更为关注用例和测试案例，而不是设计本身。目前，对于这个观点有较多的争议。
5. 测试驱动开发会导致单元测试的覆盖度不够，比如可能缺乏边界测试。在实际的操作中，和非测试驱动开发一样，当代码完成以后还是需要补充单元测试，提高测试的覆盖度。

概括起来，测试开发的基本过程如下： 

(1) 明确当前要完成的功能。可以记录成一个 TODO 列表。  (2) 快速完成针对此功能的测试用例编写。  (3) 测试代码编译不通过。  (4) 编写对应的功能代码。  (5) 测试通过。  (6) 对代码进行重构，并保证测试通过。  (7) 循环完成所有功能的开发。

本文转自cnn23711151CTO博客，原文链接： http://blog.51cto.com/cnn237111/568589，如需转载请自行联系原作者