本节书摘来自异步社区《重构与模式（修订版）》一书中的第1章1.4节测试驱动开发和持续重构，作者【美】Joshua Kerievsky，更多章节内容可以访问云栖社区“异步社区”公众号查看。
1.4 测试驱动开发和持续重构重构与模式（修订版）测试驱动开发[Beck, TDD]和持续重构，是极限编程诸多优秀实践中的两个，它们彻底改进了我开发软件的方式。我发现，这两个实践能够帮助我和公司降低过度设计和设计不足的几率，将时间用在按时地构造出高质量、功能丰富的代码上。
通过测试驱动开发（TDD）和持续重构，我们将编程变成一种对话1，从而高效地使可以工作的代码不断演变。
问：编写一个测试，向系统提问。答：编写代码通过这个测试，回答这一提问。提炼：通过合并概念、去芜存菁、消除歧义，提炼你的回答。反复：提出下一个问题，继续进行对话。这种编程节奏使我耳目一新。通过使用测试驱动开发，我们再也不用先花大量时间仔细考虑一个设计，就能够应付系统的每个细枝末节了。现在，我可以用几秒钟或者几分钟，先让原始的功能正确地工作起来，然后再重构，使它不断演进，达到必需的复杂程度。
Kent Beck为测试驱动开发和持续重构创造了一句“咒语”：“红、绿、重构”。其中的“红”和“绿”是指在单元测试工具（比如JUnit）中编写并运行一个测试时所看到的颜色。整个过程是下面这样的。
(1) 红：创建一个测试，表示代码所要完成的任务。在编写的代码能够通过测试之前，测试将失败（显示红色）。
(2) 绿：编写一些权宜代码，先通过测试（显示绿色）。这时，你用不着为难自己，非要给出没有重复、简单和清晰的设计。可以在测试通过、能够心安理得地尝试更好的设计之后，再逐步朝这个目标努力。
(3) 重构：对已经通过测试的代码，改进其设计。
听上去就这么简单，测试驱动开发和持续重构使编程领域面目一新。那些缺乏经验的程序员可能会这样想：“什么？为还不存在的代码编写测试？编写的代码通过测试之后，还需要立即进行重构？这不就是那种浪费很大、杂乱无章的软件开发方式吗？”
实际上，事情恰恰相反。测试驱动开发和持续重构提供了一种精益、迭代和训练有素的编程风格，能够最大程度地有张有弛，提高生产率。Martin Fowler称之为“迅速而又从容不迫”[Beck, TDD]，而Ward Cunningham则解释说，这种说法主要指的是持续分析和设计，与测试关系不大。
程序员需要从实践中学习测试驱动开发和持续重构的正确节奏。我认识的一位程序员Tony Mobley曾称这种开发风格为一次范型转变，其影响之巨，不亚于结构化程序设计到面向对象程序设计的转变。无论你需要多长时间来适应这种开发风格，一旦习惯之后，你将发现，再用其他任何方式开发成品代码，都会感觉奇怪、不舒服甚至非常业余。许多使用测试驱动开发和持续重构编程的人，都发现这种方式有助于：
保持较低的缺陷数量；大胆地进行重构；得到更简单、更优秀的代码；编程时没有压力。要了解测试驱动开发的细节，请研读Test-Driven Development [Beck, TDD]或者Test-Driven Development: A Practical Guide [Astels]两部著作。要对测试驱动开发有感性认识，可以参见本书的7.5.3节和6.5.2节。要了解如何持续重构，请研读《重构》[F]一书（尤其是第1章）以及本书中的重构内容。
1对话这个隐喻出自Kent Beck，借用了大哲学家苏格拉底的对话教学方式。编写测试代码就好像是向系统提问题，编写系统代码是为了回答问题，这样的对话不断反复，最后生成的就是我们所需要的系统。——译者注本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。
相关资源：敏捷软件开发.pdf