先测试还是先代码

TDD不是传统的任何一种自动化测试，更不是手工测试。首先，类似于传统测试理论中的“系统集成测试和验收测试”，TDD是针对系统需求而写的。但是TDD往往是在你只有项目领域模型的class的“空壳”（没有任何方法定义）的时候，你就去写测试代码，花2、3分钟时间写7、8行代码（通常包括3、4行断言代码）使得编程看起来有点进展的。然后编译！此时肯定出错。这时候你可以在出错的方法上面按 Ctrl+K+M (Visual Studio键盘模式)自动地在这个class内部生成方法存根，同时它会生成一行代码抛出异常。此时如果你运行，仍然会得到异常。你接下来的任务就是修改这个异常语句，同样地花2、3分钟写6、7行代码使得它看起来有点进展。然后再运行，这时候发现异常是很正常的，没有异常你就不能够知道下一步该去修改哪里。

在这个过程中，程序编译不能通过，或者编译通过但是运行时发生异常，这是正常的，而且是非常必须的。这就是TDD跟传统的编程方法的区别。

传统的编程方法，程序员自以为很了解需求了，需求都写在纸上而恐惧埋藏在心里，然后程序员去花很多天来实现需求，直到最后貌似写完了实现代码也无法对代码进行自动化测试。

TDD方法，通常不用写需求文档，你首先用代码来写需求用例，你写预想中的对象结构和方法如何被调用，以及功能单元运行的结果如何被断言。之后就直接试图编译和运行它，每一次编译或者运行错误都提示你应该补充什么代码。这时候程序员的任务就是让实现代码可以通过TDD测试，而不用把恐惧埋藏在心里。

在TDD过程中，通常你每隔5～10分钟就要运行一次程序，否则可能你的开发过程就不够敏捷，而是还是无法摆脱传统的编程习惯的束缚（很多人在这点上不注意）。这非常重要。

在你开始一个TDD测试用例的时候，首先要估计一下你产生单个TDD测试用例的“规模”。我认为不超过1天开发工作量为好。实际上我自己是大致1小时的工作做为一个测试用例。

TDD的原则之一是：不要做不必要的事情。你不要把一天之后才会考虑的东西带到编码中。不要耗费精力做过多的设计。

当你使得一个TDD测试用例可以运行通过，可以花一点时间（例如半个小时）进行小步骤的重构，把重复的中间变量删除，增加一点临时缓存。

TDD的来源来自于“头脑风暴”或者正规的需求分析，而不是你先编写好实现代码然后测试。恰好相反，TDD就是用可执行的代码来写需求（而不是用伪代码，更不是写在纸上那种需求文档）。之后开发人员就进入让TDD代码可以运行通过的状态，这样编程就可以了。

当客户的需求变化，或者架构师的描述更深入细致，于是你就可以写下一个TDD测试用例，然后让实现TDD使得它可以运行通过就OK了！

注意，当需求变化时，不是去修改系统结构！你的新的TDD测试用例应该满足新的需求描述，但是原来的TDD测试用例也应该正常地回归运行。久而久之，你就自然而然地成为一个非常棒的架构师，而用不着去背诵那些号称传道架构、模式知识的书上的鬼话。

使用TDD开发方式，当你随时需要发布产品时，2、3天之内就可以保证发布出质量很稳定的版本，一点也不会恐惧担心接下来的用户挑剔的目光。你也可以经常拿里程碑的半成品给用户试用。

TDD是协调开发团队的利器。好的XP团队会有一个习惯，每一个人在Check In代码之前都会运行不久前的TDD测试确保自己的要签入的代码跟以前的所有TDD用例相兼容。

TDD可以轻易地统计开发进度、BUG产生和重新出现的次数、责任人、开发工作量等等。

TDD不是传统的白盒测试，它在你甚至还没有写出对象和其方法的定义代码之前先就使用这个对象和方法进行断言测试。
TDD不是传统的黑盒测试，你需要每隔5~10分钟就运行这个测试程序，通过改错和重构来迭代地完成代码。
在一个项目中TDD测试有上千个，你可以随时回归运行，因此TDD不是传统的手工测试，而是纯粹的自动化测试。

阻碍TDD深入使用的问题——在我看来即使Kent Beck在发明了TDD和XP开发之后的十多年，他本人也还是没有解决这个问题——从GUI开始进行TDD。

大多数人即使进行TDD开发，也是只是在业务逻辑功能处理代码方面。而如果能够从GUI编码就开始TDD，踩阵中能消除开发中的恐惧。

但是应用程序的 UI 有很多种，有Web的、Win32的、.NET的、Mobile的、J2ME的、其它各种操作系统的，甚至Flex和Silverlight的，每一种的控件识别和模拟用户操作流程的控制方法都有一点差别，例如Silverlight的几乎所有操作都是异步的这就给许多人造成巨大的障碍，再例如在web应用中模拟一个查询订单并且录入资料这样的需要5、6步才能完成的操作。

但是只有解决了在 UI 编码开发中使用TDD的问题，才能比较彻底地掌握TDD技术。

现在大多数人回避对 UI 部分使用TDD，只是用在后台功能方面。这虽然也能大大提高产品质量和开发速度，但是毕竟还有很多纠纷靠开发完之后争吵和主管拍脑袋来解决，而不是靠事先编写大量TDD代码来协调

呵呵，我看到别人进行TDD开发最大障碍，不是他感觉困难，而是一棍子打死、声称这是理想模型。TDD是非常现实的，你不要做不必要的事情，例如不要去写不必要的文档。

TDD是一种开发态度，而不是一个供人往脸上贴金的理论流派。我遇到别人在做一个项目时先说“先要把需求用例都描述清楚”的时候，我就请他本人来描述需求用例，结果无一例外地我遇到的这些人都不愿意去描述用例——他们只是喜欢批评别人的测试用例。写TDD是程序员的一种编程态度，喜欢TDD的程序员先在单元测试中写TDD风格的测试用例，这只是一种很平常的事情，如果你实际去写过几十个，你就不再会觉得它是理想化的模型了，很多人会离不开这种开发方法。

我不太赞成传统的单元测试的那种测试方法。当你过于纠缠于内部细节，重构的方便性就变小了。

实际上我宁愿写300个TDD测试（TDD完全可以使用单元测试工具来写），也不愿意多写30个过于纠缠内部细节的单元测试。TDD就是从需求出发，站在用户的角度，或者站在产品经理的角度。有时候，我们把开发组织变为以产品经理为主导，而不是以技术经理为主导。TDD是描述需求和进行架构重构的工具，而不是单单是测试。 如果你只是写传统的单元测试，我觉得没有必要。你在源代码中写断言，这样源代码以DEBUG模式运行时就可以随时自我测试每一个功能单元的内部逻辑，而无需单独搞一个单元测试工程来测试。TDD测试可以驱动这些功能被执行，从而可以调用断言被执行。 TDD是在你实际动脑筋去想实现代码之前，用来描述用户观点的代码。所以只有TDD不可能用实现代码中的断言来代替，需要单独使用一个TDD测试程序作为引擎来驱动回归测试。