1. 测试驱动开发(Test-Driven Development)：是敏捷开发中的一项核心实践和技术，也是一种设计方法论。是极限编程的一个重要组成部分，它的基本思想就是在开发功能代码之前，先编写测试代码。
2. TDD的原理：在开发功能代码之前，先编写单元测试用例代码，测试代码确定需要编写什么产品代理。
3. TDD基本思路：通过测试来推动整个开发的进行，但测试驱动开发并不只是单纯的测试工作，而是把 需求分析，设计，质量控制量化的过程。
4. TDD的重要目的:不仅仅是测试软件，测试工作保证代码质量仅仅是其中一部分，而且是在开发过程中帮助客户和程序员出去模棱两可的需求。TDD首先考虑使用需求(对象、功能、过程、接口等)，主要是变成测试用例框架对功能的过程和接口进行设计，而测试框架可以持续验证。
5. TDD优缺点：
a.优点：（在任意一个开发点都可以拿出一个可以使用，含少量bug并具有一定功能的产品。）
『充满吸引力的优点』
① 完工时完工。表明我可以很清楚的看到自己的这段工作已经结束了，而传统的方式很难知道什么时候编码工作结束了。
② 全面正确的认识代码和利用代码，而传统的方式没有这个机会。
③ 为利用你成果的人提供Sample，无论它是要利用你的源代码，还是直接重用你提供的组件。
④ 开发小组间降低了交流成本，提高了相互信赖程度。
⑤ 避免了过渡设计。
⑥ 系统可以与详尽的测试集一起发布，从而对程序的将来版本的修改和扩展提供方便。
⑦ TDD给了我们自信，让我们今天的问题今天解决，明天的问题明天解决，今天不能解决明天的问题，因为明天的问题还没有出现(没有TestCase)，除非有TestCase否则我决不写任何代码；明天也不必担心今天的问题，只要我亮了绿灯。
『不显而易见的优点』
① 逃避了设计角色。对于一个敏捷的开发小组，每个人都在做设计。
② 大部分时间代码处在高质量状态，100％的时间里成果是可见的。
是由于可以保证编写测试和编写代码的是相同的程序员，降低了理解代码所花费的成本。
③ 为减少文档和代码之间存在的细微的差别和由这种差别所引入的Bug作出杰出贡献。
④ 在预先设计和紧急设计之间建立一种平衡点，为你区分哪些设计该事先做、哪些设计该迭代时做提供了一个可靠的判断依据。
『有争议的优点』
① 事实上提高了开发效率。每一个正在使用TDD并相信TDD的人都会相信这一点，但观望者则不同，不相信TDD的人甚至坚决反对这一点，这很正常，世界总是这样。
② 发现比传统测试方式更多的Bug。
③ 使IDE的调试功能失去意义，或者应该说，避免了令人头痛的调试和节约了调试的时间。
④ 总是处在要么编程要么重构的状态下，不会使人抓狂。（两顶帽子）
⑤ 单元测试非常有趣。
b.缺点：增加代码量。测试代码是系统代码的两倍或更多。
6. 测试驱动开发的效果：以可执行的形式文档化你的需求，迫使你分清职责隔离依赖以驱动你的设计，编织安全网以便将Bug扼杀在摇篮的状态，防止其逃逸。
7. 测试人员在新的特性还没开发完成之前做什么？
除了提前编写测试用例，而需要测试人员一起参加一项重要的活动，就是参与特性验收条件的制定。
8. 测试驱动开发的基本过程
a. 快速新增一个测试用例 新的TestCase
b. 编译所有代码，刚刚写的那个测试很可能编译不通过 原始的TODO List
c. 做尽可能少的改动，让编译通过 Interface
d. 运行所有的测试，发现最新的测试不能编译通过 －(Red Bar)
e. 做尽可能少的改动，让测试通过 Implementation
f. 运行所有的测试，保证每个都能通过 －(Green Bar)
g. 重构代码，以消除重复设计 Clean Code That Works
9. TDD与AMDD(敏捷模型驱动开发)相比
·TDD缩短了编程反馈周期，而AMDD缩短了建模反馈周期
·TDD提供详细规范（测试），而AMDD提供一般规范（数据模型）
·TDD有助易于开发中编写搞质量代码，而AMDD有助于在项目中桶项目负责人和开发人员进行有效地沟通
·TDD能对你开发的软件有一个具体形态描述，AMDD能让你的团队，包括项目负责人，向着一个共有的目标前进；
·TDD提供了具体的文档的具体反馈，而AMDD对具体文档的允许口头反馈（具体反馈需要程序员在代码中证明，而那样就是非敏捷模型的技术了）
·TDD可同构关注代码的调用和可测试来看你的设计是否整洁，而AMDD提供一个机会让你在写代码之前思考
·TDD是非可视化的，而AMDD是可视化的
·两种技术对传统开发人员来说都是新的，搞不好会让他们不爽
·两种结束都支持螺旋式开发
10. TDD = TFD (Test First Development ) + 重构
相关阅读：
