肯特·贝克（Kent Beck） 软件工程领域泰斗、测试驱动开发理念提出者、极限编程之父，在设计模式、测试驱动开发和极限编程领域有很深的造诣，被誉为“计算机软件行业最具创造性才能的领导者之一”和“Java领域最具影响力的10位技术领袖之一”。他为软件行业的发展做出了卓越的贡献。早在1993年，他就与UML之父携手倡导软件开发的模式定义，推动了软件开发模式在软件行业的发展；更突出的贡献是，他提出并推动的极限编程方法学，以及他与Erich Gamma共同打造的JUnit工具，引发了敏捷开发的热潮。他著述颇丰，撰写了《解析极限编程：拥抱变化》、《实现模式》等多本经久不衰的经典著作，这些著作被翻译为多种文字，在世界范围内广泛传播和流行。

白云鹏　资深软件开发工程师，对软件过程有深刻理解，曾在微软（美国）总部参与多个项目的全程发布。研究方向是：软件过程改进、测试新技术应用和软件算法分析与设计。出版有《软件测试人员（Java·高级）》等著作。

现在就可以运行简洁的代码！这看起来根本不可能，因为编程背后饱含了复杂性与痛苦的挣扎。而测试驱动开发（TDD）回应了这个悖论，看起来好像不合乎逻辑——在编写程序前先测试它。这是全新的想法吗？根本不是。自计算机技术发展之初，就有程序员明确提出在编程前要给出精准的输入和输出。TDD是沿着这个想法深入下去的产物，结合了现代的编程语言和编程环境，烹制出了如今可运行的简洁代码这一“美味佳肴”。
程序员每天都面临复杂的挑战，且很难确定哪种解决方法是最好的。这些棘手的项目多半会造成巨大的压力并产出糟糕的代码。为了获得力量和勇气来克服这些看起来不可能完成的任务，程序员必须要依靠TDD技术，这个技术支持简单的设计和测试套件，必将给人以足够的自信心。TDD通过自动化测试来驱动开发，并且去掉重复部分，使得任何开发者都能够轻而易举地编写出高质量的代码，无论代码有多复杂。另外，TDD鼓励开发者更迅速地学习，更清晰地交流，并且找到具有建设性的反馈信息。

本书主要内容：
解决复杂的问题，从简单的情况着手，深入到更复杂的情况中去。
在编写程序代码前编写自动化测试。
塑造一个设计，然后通过重构每次添加一个设计上的构思。
为更复杂的逻辑创建测试，包括反射和异常。
使用一些模式来决定编写哪些测试。
使用xUnit（众多面向程序员的测试工具中的核心框架）创建测试。
本书从始至终贯穿了两个TDD项目，展示了程序员可以轻而易举且卓有成效地改进代码质量的技术。这些实例涉及各式各样的模式和重构方法。测试驱动开发基于敏捷方法和快速开发策略，一定会启迪读者接受这些影响深远的技术。

“可运行的简洁的代码”是Ron Jeffries关于测试驱动开发（TDD）目标的精辟概括。有一大揽子理由能够说明，可运行的简洁的代码是值得实现的目标：
　　 它是一种可预测的开发方式。你会知道自己何时可以完成，而不必担心因缺陷而拖得太久。
　　 它会给你全面认识代码的机会。如果你草率地采用了自己最初的想法，那就再也没有时间来考虑另外更好的想法了。
　　 它让使用我们软件的用户生活变得更加美好。
　　 它使成员之间相互信赖。
　　 它本身的编写过程也让人感觉很棒。
　　但我们如何才能得到简洁的可运行的代码呢？很多因素使我们与简洁的代码渐行渐远，甚至导致代码无法运行。其实，不用为我们的担心浪费太多笔墨，这样做就可以：使用自动化测试驱动开发，一种叫做“测试驱动开发（简称TDD）”的开发方法。在测试驱动开发中，我们：
　　 仅当自动化测试失败的时候才编写新的代码。
　　 去掉重复的部分。
　　这是两项比较简单的原则，但这会产生出一个或一组技术方面复杂的行为准则，例如：
　　 我们必须参考每次修改后代码运行状况的反馈，逐渐完成设计。
　　 我们必须自己编写测试，因为我们不能指望其他人编写测试。
　　 我们的开发环境必须对细微的修改迅速做出响应。
　　 我们的设计必须遵从高内聚、低耦合的原则，这样便于实施测试。
　　那两项简单的原则预示了编程任务的先后顺序：
　　1. 红色指示条—编写一个无法工作的简单测试，当然，这个测试起初甚至都无法通过编译。
　　2. 绿色指示条—迅速使测试工作起来，这个过程可谓想方设法，甚至不择手段。
　　3. 重构—去掉单纯由于使测试工作起来而产生的重复部分。
　　红色指示条－绿色指示条－重构—此乃TDD的经典三部曲。
　　先假设这样的编程方式是成立的，进一步讲，这种方式可使代码缺陷的密度降低，还可以使所有相关人员对工作主旨若网在纲。如果这样的话，只在测试失败时才需要编写的代码还有其社会意涵：
　　 如果可以将缺陷的密度降到足够低的话，那么，质量保证人员的工作状态就能够变被动为主动。
　　 如果可以尽可能地减少令人不悦的意外发生，那么，项目管理人员就能够非常精确地估算出日常开发工作所需的人手。
　　 如果可以将技术讨论的主题构思得足够清晰，那么，软件工程师就可以亲密无间地合作，而非拉锯式地工作。
　　 同样，如果可以将缺陷的密度降到足够低，那么，我们每天都可以发布带有新功能的软件，这样会与客户建立新的业务往来。
　　诚然，这个理念并不复杂，但其背后的动机又是什么呢？为什么一位软件工程师要插手编写自动化测试以外的工作呢？为什么一位软件工程师能够给出高屋建瓴的设计却以细微的步伐前行呢？勇气使然。
勇气（Courage）
　　测试驱动开发是一种在编程过程中管理担忧的方式。这不是杞人忧天之虑，而是合理的担忧，但是否合理的问题是很难从一开始就看出来的。如果疼痛的自然反应是喊“停！”，那么担忧的自然反应则是喊“当心！”。当心历来是好事，但担忧却有不少其他的副作用：
　　 担忧使你举棋不定。
　　 担忧使你疏于交流。
　　 担忧使你回避反馈。
　　 担忧使你郁郁寡欢。
　　这些作用对于编程都是无益的，尤其是在编写有难度的程序时。因此，你该如何面对困难的局面呢？并且：
　　 尽快开始具体地了解一些东西而不是试探。
　　 更加清晰地交流而不是闭口不言。
　　 找出具体的有用的反馈而不是回避。
　　 克制负面情绪。
　　把编程想象成使用曲柄从一口井中摇上一桶水的过程。当水桶不太大时，自由旋转的曲柄还不错。当水桶比较大并且装满水，再把水桶提上来的时候，你就会感到累了。你需要一个在转动曲柄的间隙能够使你休息的棘齿装置。越重的桶，就需要棘齿装置的齿越密。
　　测试驱动开发当中的测试就像棘齿装置的齿。一旦测试运行起来，你就知道它会这样子运行下去了。比起测试坏掉的情况，你已经朝着一切运行如仪的目标又迈进了一步。现在，还可以使下一个，下下个和再下一个测试运行。以此类推，越是棘手的编程问题，每个测试的覆盖面要越小。
　　阅读本人著作《Extreme Programming Explained》的读者会注意到描述极限编程（XP）和测试驱动开发在语气上的差异。TDD与XP有所不同。XP会要求你必须准备这样那样很多东西。但TDD却没有那样地泾渭分明。TDD很明确地知道，设计和现实之间肯定存在很多差异，还告诉了你控制这种差异的方法。“我要是用一周时间做书面上的设计，然后用测试驱动代码如何？这算是TDD吗？”当然算啦！这就是TDD。你意识到了设计与现实之间的差异，并且有意识地掌控它。
　　即便如此，大多数学习TDD的人发现他们的编程行为被永远地改变了。测试感染（Test Infected）是Erich Gamma发明的用来描述这一转变的说法。你可能会发现自己比以前会写更多的测试，会发现使用更小的步伐推进要比曾经自己想象的要合理。另一方面，一些软件工程师学习TDD后保留了他们原有的编程行为，在一些特殊的情况下，当常规的编程方法不奏效的时候，他们才拿出TDD救急。
　　当然存在不能仅仅（或者根本不能）由测试来驱动的编程任务，例如，软件安全性和并发问题，使用TDD去一板一眼地证明这两方面与需求的吻合度就会显得捉襟见肘。尽管事实上软件的安全性本质上依赖于无缺陷的代码，但也依赖于使软件变得安全所使用方法的人为判断。微妙的并发问题是不能通过运行代码就能可靠再现的。
　　一旦你阅读完这本书，你应该准备：
　　 从简单的地方着手。
　　 编写自动化测试。
　　 通过每次重构添加一回设计上的构思。
　　本书分为三部分。
　　第一部分，货币实例—一个典型的使用TDD编写的示例代码。这个示例是数年前我从Ward Cunningham那里得到的，而且在多币种算法的例子中使用过多次。这个例子会使你学到在编码前就编写测试，并且逐渐地完成设计。
　　第二部分，xUnit实例—一个为自动化测试开发的框架，测试包含反射和异常且拥有比这更复杂逻辑的例子。这个例子还会给你引入xUnit架构，这是众多面向程序员的测试工具之关键所在。在第二个例子中，你会学到用比前一个例子中更小的步伐来工作，包括那种计算机科学家们所钟爱的自我提醒式的念叨。
　　第三部分，测试驱动开发的模式—包括了决定可以编写哪些测试这样的模式，如何使用xUnit编写测试，以及精选的设计模式和在示例中使用的重构方法。
　　我将示例描述为结对编程的场景。如果你喜欢在闲逛前先查看地图的话，那么也许你要直接去看第三部分的那些模式，并且尝试其中所举的那些例子。如果你倾向于只是闲逛，事后再去看看地图你都到过哪里的话，那就试着逐个阅读书中的示例吧，当你想知道某个技术的更多细节时可以查阅这些模式，把这些模式作为参考。本书的几位审阅者说，当他们启动编程环境，输入代码并运行他们所读到的程序时，最大的收获来自于这些示例之外。
　　关于这些示例需要注意的一点是，多币种的计算和测试框架这两个例子显得比较简单。但却也存在着（我曾经见过）使用复杂，不雅且愚蠢的方法解决相同问题的情况。我本来可以选择其中某个复杂、不雅、愚蠢的方法来给本书以“真实感”。但是，我的目标是编写可运行的简洁代码，希望你的目标也是如此。在开始这些被认为非常简单的例子之前，花费15秒钟想象一下，一个所有代码都简洁明了，不存在复杂解决方法的编程世界，仅有复杂的问题需要认真思考。那么，TDD完全可以帮助你得偿所愿。

计算机\软件工程

现在可以运行的简洁的代码！这看起来根本不可能，因为编程背后饱含了复杂性与痛苦的挣扎。而测试驱动开发（TDD）回应了这个悖论，看起来好像不合乎逻辑——在编写程序前先测试它。这是全新的想法吗？根本不是。自计算机技术发展之初，就有程序员明确提出在编程前要给出精准的输入和输出。测试驱动开发是沿着这个想法深入下去的产物，结合了现代的编程语言和编程环境，烹制出了如今可运行的简洁代码这一“美味佳肴”。
开发者每天都面临复杂的挑战，且很难确定哪种解决方法是最好的。这些棘手项目多半会造成出巨大的压力并产出糟糕的代码。为了获得力量和勇气来克服这些看起来不可完成的任务，程序员必须要依靠TDD技术，这个技术支持简单的设计和测试套件，必将给人以自信和信心。TDD通过自动化测试来驱动开发，并且去掉重复部分，使得任何开发者都能够轻而易举地编写出没有缺陷的代码，无论代码有多复杂。另外，TDD鼓励开发者迅速地学习，更清晰地交流，并且找到具有建设性的反馈信息。
本书主要内容：
 解决复杂的问题，从简单的情况着手，深入到更复杂的情况中去。
 在编写程序代码前，编写自动化测试。
 塑造一个设计，逐渐地通过重构，每次添加一个设计上的构思。
 为更复杂的逻辑创建测试，包括反射和异常。
 使用一些模式来决定编写哪些测试。
 使用xUnit（众多面向程序员的测试工具中的核心框架）创建测试。
本书从始至终贯穿了两个TDD项目，展示了程序员可以轻而易举且卓有成效地改进代码质量的技术。这些实例涉及了各式各样的模式和重构方法。测试驱动开发基于敏捷方法和快速开发策略，一定会启迪读者接受这些未被充分推广但却影响深远的技术。

（美）Kent Beck 著：暂无简介

白云鹏 译：暂无简介

本书早在2002年由培生教育出版集团（Pearson Education）首次出版以来，十余年间，敏捷方法爱好者、业内专业人士将它口口相传，经久不衰。原因何在？我认为这是人们追寻更好的方法，期以获得更丰厚回报的天性使然。测试驱动开发（Test-Driven Development，TDD）始于20世纪90年代，历经岁月，成于2003年，也即本书首次出版之时。
　　从早期的面向过程程序开发到后来的面向对象软件开发，随之诞生了软件构件化、工程化的开发方法。在软件开发方法学中，测试驱动开发较之其他开发方法学可谓历久弥新，自诞生之日就一直受到业内高度关注，也从不乏勇于尝试和探索的有识之士。正如本书作者Kent Beck先生所说，测试驱动开发是一种正确的做事方法。这种方法打破了传统软件开发流程，提出了测试优先（Test First）的编程模式，其中的优点无须赘言。
　　本人也在实践当中尝试了书中的理论。整个过程轻巧安全，步步推进，给编码工作带来了耳目一新的感觉。译竣之后，也深感此书犹如测试驱动开发之蓝本，不负盛名。
　　本书由我负责翻译并整理，此过程中的辛酸苦辣一言难尽，但也感到与Kent Beck这样一位出色的业界领袖巨笔际会是一个享受的过程。在成书过程中，机械工业出版社的吴怡编辑给予了莫大的支持和鼓励。承荷兰威科集团（Wolters Kluwer）庾戈华工程师的悉心帮助，解决了不少翻译过程中遇到的困惑。微软美国总部的香钦柏工程师、美国密歇根大学安娜堡分校的葛瑾女士也审阅了书稿，提出了不少中肯建议。借此机会谨致谢忱。还要感谢给予了我很多支持和关心的家人，希望本书的出版，给你们带来快乐！

译者序
前言
致谢
引言
第一部分　货币实例
第1章　多币种货币实例 2
第2章　简并对象 9
第3章　定义相等性 12
第4章　实例变量私有化 16
第5章　法郎的自白 19
第6章　相等性再定义 22
第7章　美元和法郎 27
第8章　制造对象 29
第9章　正在进行的times方法 33
第10章　有趣的times方法 38
第11章　万恶之源 43
第12章　总算谈到加法了 46
第13章　到达我们的预期 51
第14章　变化 56
第15章　多币种货币 61
第16章　总算谈到抽象了 65
第17章　货币回顾 69
第二部分　xUnit实例
第18章　走进xUnit 76
第19章　设置主线 81
第20章　后续的清理 85
第21章　计数 89
第22章　处理未通过的用例 92
第23章　好美妙的测试套件 95
第24章　xUnit回顾 101
第三部分　测试驱动开发的模式
第25章　测试驱动开发模式 104
第26章　红条模式 113
第27章　测试模式 121
第28章　绿条模式 128
第29章　xUnit框架下的模式 133
第30章　设计模式 141
第31章　重构 155
第32章　掌握测试驱动开发 165
附录A　影响图 178
附录B　斐波那契数列 181
后记 184