1. TDD
TDD指的是Test Drive Development，很明显的意思是测试驱动开发，也就是说我们可以从测试的角度来检验整个项目。大概的流程是先针对每个功能点抽象出接口代码，然后编写单元测试代码，接下来实现接口，运行单元测试代码，循环此过程，直到整个单元测试都通过。这一点和敏捷开发有类似之处。
2. 为什么要使用TDD
部分团队成员无缘参与需求、规范或用户故事的制定；
大部分乃至全部测试都是手动的，抑或根本就没有测试；
虽然使用了自动化测试，但并未检测出真正的问题；
编写并执行自动化测试的时间太晚，无法给项目带来真正的价值；
总是有更紧急的问题需要处理，没法腾出专门用于测试的时间；
整个团队分为测试、开发和功能分析小组，而这些小组常常不能同步；
无法重构代码，因为担心这样做会破坏既有的功能；
维护成本高；
上市时间过长；
客户觉得交付的产品不符合要求；
文档从来都不是最新的；
害怕部署到生产环境，因为结果无法预料；
常常无法部署到生产环境，因为运行回归测试的时间太长；
团队为搞清楚某些方法或类的作用花费的时间太多。
测试驱动开发并不能神奇地解决所有这些问题，而只为我们找到解决方案指明方向。世上没有灵丹妙药，但如果有什么开发实践能让众多层面的情况大不相同，那就是TDD。
3. TDD步骤
测试驱动开发是一个过程，依赖于不断重复极短的开发周期。它基于极限编程（XP）的测试优先理念，倡导采用可高度信赖的简单设计。驱动这个流程前行的开发周期称为“红灯-绿灯-重构”。
这种流程本身很简单，由几个反复进行的步骤组成：
(1) 编写一个测试；
(2) 运行所有测试；
(3) 编写实现代码；
(4) 运行所有测试；
(5) 重构；
(6) 运行所有测试。
鉴于测试是在实现前编写的，因此它应该不能通过。如果通过了，就说明测试是错误的：要么它描述的功能早已存在，要么编写不正确。编写测试期间处于绿灯状态昭示着存在错报的问题，对于这样的测试，应将其删除或进行重构。
4. TDD的好处
(1) 保证代码的质量
(2) 提高开发效率
(3) 能够更好的满足测试
(4) 减少自测的时间
(5) 能够成为更好的代码说明文档
5. 总结
并不是所有的项目都适合TDD这种模式的，我觉得必须具备以下几个条件。
首先，项目的需求必须足够清晰，而且程序员对整个需求有足够的了解，如果这个条件不满足，那么执行的过程中难免失控。当然，要达到这个目标也是需要做一定功课的，这要求我们前期的需求分析以及HLD和LLD都要做得足够的细致和完善。
其次，取决于项目的复杂度和依赖性，对于一个业务模型及其复杂、内部模块之间的相互依赖性非常强的项目，采用TDD反而会得不尝失，这会导致程序员在拆分接口和写测试代码的时候工作量非常大。另外，由于模块之间的依赖性太强，我们在写测试代码的时候可能不采取一些桥接模式来实现，这样势必加大了程序员的工作量。