TDD的三条军规

　　◆　除非这能让失败的单元测试通过，否则不允许去编写任何的产品代码。
　　◆　只允许编写刚好能够导致失败的单元测试。 （编译失败也属于一种失败）
　　◆　只允许编写刚好能够导致一个失败的单元测试通过的产品代码。

　　对于任何功能，一定要从编写它的单元测试开始；但是到了原则2，你就不能再为那个单元测试写更多内容。只要一出现该单元测试代码编译失败，或是断言失败，你就必须停下来开始编写产品代码；但是到了原则3，你就只能编写产品代码，直到让测试编译成功或通过断言为准。

　　仔细想想，就会发现如果不是去让一些东西编译或是执行，你就根本没办法去写代码。确实，这也正是关键所在。我们所做的任何事情（无论是写测试，写产品代码，或是重构），都要保持系统能够一直运行。跑通测试的时间间隔应该是以秒或是分钟级的，即使那只有10分钟，也都太长了。

　　想了解实际的操作过程，可以看看“保龄球游戏中的Kata”（译注2）一文。

　　现今有很多程序员，每当他们头一次听到这种技术的时候，会想：“这种做法太愚蠢了！”“这会让我慢下来，这是时间和精力的浪费，让我无法思考，无法设计，还会打乱我的思路。”然而，试想，当你走进一个房间，里面都是用这种方式工作的人们，会发生什么情况？你随便选个时间，随意找个人，一分钟以前，他们所有的代码都跑通过。

　　让我再重复一遍：一分钟以前每个人的代码都能跑通！不管你找谁，也不管你何时去找，一分钟以前他们所有的代码都跑通了！

　　如果你所有的代码自始至终都能跑通，那么你会多长时间用一次调试器？答案是，不会太经常。只要敲几下^Z就能很容易的恢复这些代码到跑通时的状态，然后再试着把前几分钟的代码写一遍即可。而如果你不经常调试，那么会省去多少时间呢？而现在你花在调试上的时间又有多少呢？一旦你有调试过，你又要花上多少时间来修复这些bug呢？如果你能够大大减少这些时间的话，又会如何呢？

　　好处还不只这些。如果你采用这种方法，那么每小时你都会产生好几个测试；每天就有十几个；每个月就几百个；一年下来，你所编写的测试就会有数千个。你可以保留着这些测试而且在任何你希望的时候去运行它们！什么时候运行它们呢？随时！只要你做了改动，就去运行它们！

　　有些代码已经混乱不堪了，可是我们为何不去清理它们呢？我们担心会破坏它们。但如果我们拥有测试，我们就有理由确信这些代码不会被破坏，或是说我们可以很快的就找到被破坏的地方。如果我们有了这些测试，我们就对代码发生改变无所忌惮。如果我们看到混乱的代码，或是一个不清晰的结构，可以毫无顾虑地清理它。因为有了测试，代码重新变得易修改了；因为有了测试，软件重新变“软”了。

　　好处还不只这些。如果你想要知道如何去调用一个特定的API，就会有一个测试能够告诉你；如果你想要知道如何创建一个特定的对象，就会有个测试能告诉你。你想知道的任何有关这个系统的，都有一个测试能够去示意。这些测试就像是小型的设计文档，小型的代码示例，描述了系统的工作和使用方式。

原文转自：http://www.ltesting.net