TDD的全称是Test Driver Development，测试驱动开发。就是开发要以测试为驱动。编码之前，测试先行。代码都没有，我如何测试，我连要测的对象都没有啊？这好像是个问题。

　　TDD的哲学为我们解答了这个问题：先编写测试用例（没有代码之前这些测试用例一个也通不过），然后再写代码让这些测试用例通过。更进一层的讲就是：编写足够的测试用例使测试失败，编写足够的代码是测试成功。我们编码的目的更加明确的。

　　TDD是大名鼎鼎的极限编程的一个最重要的设计工具之一（另一个是重构（Refactoring），这是它的荣誉，下面我列举几点它实际的好处。

　　TDD带来的好处有：

　　1、你会更加站在用户的角度去看你将要完成的产品，你要尽可能想到用户所有进行的操作。而不是从程序员的角度想用户应该会如何去使用我们的产品。

　　2、测试用例是在对功能进行测试。在写代码之前先写测试用例，可以对我们编写代码提供指导性的参考。防止我们漏掉一些功能。

　　3、它使我们对自己代码有了信心，因为我们事先设计好的所有测试用例都Pass了。

　　4、如果在更改代码后测试用例不能通过，我们可以根据不能通过的测试用例精确的定位问题，并轻而易举的解决的这个bug。

　　5、哈！我们的一整套完备的测试用例在这里替我们把关（把的什么关？），我们就可以十分安全的使用极限编程的另一个最重要的工具——重构。重构改变的是代码的内部结构，而不会改变外部接口功能。知道在做重构时测试用例是把的什么关了吧！很明显，测试用例是保证我们在进行重构时，不会影响到代码的外部接口功能。所以我刚刚说，我们进行的重构是十分安全的。

　　6、基于第5点，我们找到了重构的信心，必要时候你还可以痛痛快快的并且满怀信心的对代码做一场大的变革。这样我们的代码变得干净了，扩展性、可以维护性以及易理解性纷至沓来。

　　TDD有这么多好处，但它也不是免费的午餐，它需要我们有设计完备的测试用例的能力（这项能力是长期理论与实践的结合体），否则你将会吃了亏编写了一大堆测试用例，却没测到点子上。可怕的是，你还对你“测试通过”的糟糕的代码满怀信心。

　　TDD的主旨是高效，可能这个高效不是非常高的开发速度。

　　通常的软件开发过程是先写功能，然后再写测试。甚至有时候只进行某些方面的测试，或者有省事的就略去了某些细小功能的测试，或者是忘了对这些模块的测试。

　　这些看起来对软件影响不大，但是似乎有点过于自信了。因为我们是人，不是神，所以难免会出一些这样或那样的错误，而这些小的问题在项目整合起来以后进行排错是非常令人头疼的。

　　TDD的思想是以测试推动开发进程。因为我们在软件开发之前，每个程序单元的功能都已经确定了。程序员在理解完整个程序需求以后，直接进行开发，有可能会因为种种原因考虑不很周全，似乎功能实现的没有问题了，但是其中却可能隐藏着非常可怕的Bug。TDD促使开发人员先根据程序单元的功能编写测试代码，就像是先建一个模型，然后向里面浇注合适功能的代码。最后满足所有的测试验证了，才能正常通过测试，这个程序单元才算完成。

　　这样消除了开发人员主观性的对程序单元健壮性的评估，更客观的验证每一个程序单元的功能实现以及可能出现的Bug。

　　当然，这些操作都需要有大量的代码支持，所以费事是在所难免的，但是这点“费事”与健壮性非常强的代码相比，有些人还是偏向于使用TDD。

　　首先站在客户方代码的立场，可以获得更好的api。

　　其次可以改善软件质量，支持重构。

　　其三，大幅减少debug时间。

　　前期投入大，后期能大幅缩短开销，将问题发现在最源头

　　提供明确的目标

　　你很清楚， 一旦结束（测试通过）， 你的工作就完成了（假设你的测试写的很好）. 测试代码会为代码建立一个自然的边界， 使你把重点集中在当前任务上. 一旦测试通过， 就有确切的证据证明你的代码能工作. 相对于人工的测试用户界面或者比较日志文件中的结果，  在一个xUnit框架中运行自动化测试， 速度要快几个数量级. 大多数xUnit测试的运行只需几微秒， 而且大多数采用TDD的人都会一天运行数次测试. 在许多开发小组中， 将代码上传配置库前， 必须成功地通过测试。