本书分三部分，共9章。第一部分（第1~3章）主要阐述测试的目的与原因，并分析作为常用工具的测试替身的作用。第1章先从整体阐释测试先行所带来的价值，以及各种对测试和测试质量的影响。第2章定义了如何才能写出优秀的测试。第3章谈及现代程序员最基本的工具之一——测试替身。第二部分（第4~6章）的目标是帮助我们更好地识别并修复测试代码中的坏味道。第4章展示破坏测试可读性的坏味道。第5章继续对破坏可维护性的测试提供建议。第6章涉及有关脆弱或不可靠的测试坏味道。第三部分（第7~9章）涉及Java程序员在编写测试时随时可能碰到的话题。第7章介绍可测的设计的定义与作用。第8章探讨JVM语言的共生，以及如果用另一门语言来测试Java代码。第9章专门讨论对构建进行加速的问题。此外还包括两个附录，附录A介绍了使用JUnit编写测试的入门知识。附录B探讨通过JUnit的API来扩展其内置功能。
资深敏捷技术实践专家撰写，系统且深入地阐释单元测试用于软件设计的工具、方法、原则和最佳实践
深入剖析各种测试常见问题，包含大量实践案例，可操作性强，能为用户高效编写优秀测试提供系统实践指南
一本出色、权威的指南。它可以帮助你提高生产力和开发效率。
—— Roger Cornejo，GlaxoSmithKline
这本书改变了我对Java开发过程的看法，强烈推荐！
—— Phil Hanna，SAS Institute, Inc.
这本书阐释了书写高质量代码的常识性方法。
—— Frank Crow Sr. ，Progeny Systems Corp.
非常有用，即使你采用.NET编写代码。
—— J. Bourgeois，Freshly Coded
如果单元测试是你的噩梦，那就来读这本书吧！
—— Franco Lombardo，Molteni Informatica
首先测试组件，然后将它们组装成完整的应用程序，这样你将会得到更优秀的软件。Java程序员已有几十年的经验来精心地设计测试，用于预测问题和识别代码中确定与未知的依赖，人们既能以隔离的方式测试组件，又能在完整的应用程序环境中进行测试。
本书旨在教Java程序员书写优秀的单元测试，做到简洁、富于表达力、有用并且可维护。除了提供清晰的解释和易懂的例子，本书还介绍了行为驱动开发和实例化需求等新兴技术。
作者简介
Lasse Koskela 资深敏捷技术实践专家、敏捷教练、培训师、顾问和程序员，具有数十年计算机程序设计和开发经验。他精通多种编程语言，尤其对Java、Ruby、C/C++有独到见解，热衷于编程和追逐前沿技术，在程序设计、软件工程、项目管理等多个领域颇有建树。目前他主攻开源项目，帮助企业提高生产力，而且经常在世界各地的会议上发表演讲。除本书外，他还著有《测试驱动开发的艺术》。
译者简介
申健 江湖人称“申导”，创客、工匠、敏捷教练、软件开发顾问，致力于启发创意、促进协作、交付价值的事业。
1994年迷上计算机编程。从南京大学毕业后，在跨国企业从事近十年的研发和管理工作，涉及通信、金融、互联网等领域，拥有丰富的移动应用程序和面向服务分布式系统的项目经验，擅长使用不同的技术来实现面向服务的分布式架构设计和整体解决方案，熟悉J2EE、Python、嵌入式C、Node.js技术及iOS等平台。2007年开始进入敏捷开发实践，拥有CSP、CSM和CSPO等认证。他曾在诺基亚西门子担任高级工程师和研发经理，在渣打银行担任资深工程师和敏捷教练等。
目前主要从事外部敏捷教练工作，提供组织转型和技术实践的咨询与培训服务。同时还是Scrum Alliance注册讲师、InfoQ中文站编辑、中国敏捷教练组成员，以及敏捷之旅、ScrumGathering、QClub等社区活动的讲师与组织者。他曾翻译《SOA with REST》等书籍。
个人网站：www.JackyShen.com
内容简介
这是一本关于单元测试的系统实践指南，由资深敏捷技术实践专家撰写，不仅全面阐释了单元测试用于软件设计的工具、方法、原则和最佳实践，而且对各种测试常见问题进行了深入分析，包含大量实践案例，可操作性强，能为用户高效编写优秀测试提供有效指导，让组织持续创造成功的产品和服务。
本书分为三部分，共9章。第一部分（第1~3章）主要阐述测试的目的与原因，并分析作为常用工具的测试替身的作用。第1章先从整体阐释测试先行所带来的价值，以及各种对测试和测试质量的影响。第2章定义如何才能写出优秀的测试。第3章讨论现代程序员最基本的工具之一——测试替身。第二部分（第4~6章）的目标是帮助我们更好地识别并修复测试代码中的坏味道。第4章展示破坏测试可读性的坏味道。第5章继续对破坏可维护性的测试提供建议。第6章涉及有关脆弱或不可靠的测试坏味道。第三部分（第7~9章）涉及Java程序员在编写测试时随时可能碰到的话题。第7章介绍可测的设计的定义与作用。第8章探讨JVM语言的共生，以及如何用另一门语言来测试Java代码。第9章专门讨论对构建进行加速的问题。此外还包括两个附录，附录A介绍使用JUnit编写测试的入门知识。附录B探讨通过JUnit的API来扩展其内置功能。
过去10余年间，Java开发者显著地青睐开发者测试。如今，计算机科学专业的毕业生无人不知自动化单元测试及其在软件开发中的重要性。这个想法很简单——确保我们的代码能工作并且一直能工作——但是该技能需要花很大力气去学习。
编写测试、学习JUnit的测试框架，这些都不难。要真正地掌握编写自动化单元测试实践，需要花大量时间在阅读并改善测试代码上。这种持续的测试重构能够尝试用不同方式来表达意图、组织测试的不同行为、用测试构建各种用到的对象——这才是一种务实的方式，用来自我学习和培养对单元测试的感觉。
这种感觉是关于哪些是优秀的单元测试，而哪些不那么优秀。有些是绝对的真理（比如完全在重复代码内容的注释就是冗余的，应该被删除），但大多数关于单元测试的知识都取决于上下文。通常意义上的优秀在特定条件下可能却很糟糕。同样，一般认为糟糕和应当避免的想法有时却是正确的做法。
原来，找到优秀方案的最好方式就是尝试一个看似可行的方法，识别该方法的问题，然后改变该方法从而消除讨厌的部分。通过重复这个过程，不断地评估和进化，最终你会找到一个可行的方案，它闻起来没那么臭。你甚至会说那是相当优秀的方式！
考虑到这种复杂性，本书采用了一种风格和结构，那就是我们不会告诉你怎么做，也不会告诉你怎么编写单元测试。相反，我打算给你一个坚实的基础，让你知道哪些是我们希望测试表现出的属性，然后给你尽可能多的例子来培养你对测试坏味道的感觉——帮你注意到测试中的不合时宜之处。
受众
本书针对想要提高单元测试编写质量的各个层次的Java程序员。虽然我们提供了附录来教给你测试框架（JUnit），但我们的主要目标是帮助已经了解单元测试的Java程序员，用其喜欢的测试框架来编写更好的单元测试。不管你已经写了多少单元测试，我们肯定你仍然可以做得更好，阅读本书或许能带你揭示一些难以言喻的想法。
路线图
本书提到了多个方面的挑战，因此需要良好的结构来支撑这些方面。深思熟虑后（源自于多次迭代中的失败尝试），我们决定将本书分为三个部分。
关于更好的测试，第一部分先介绍了我们要达到的目标，以及它们为什么是可取的。其中的三章展示了编写优秀测试的基本工具和简单指南。
第1章从自动化单元测试的价值主张开始。我们通过考虑程序员生产力的多种因素来建立价值，以及编写优秀自动化单元测试如何有助于生产力，或避免耽误我们。
第2章提高了标准，尝试定义什么是优秀的测试。该章中的属性和注意事项是第二部分的核心基础，涉及测试的可读性、可维护性和可靠性。
第3章进一步介绍测试替身，作为编写优秀测试的重要工具。我们并不是为了使用测试替身而使用，而是深思熟虑地用好它们。（它们不是你想要的银弹。）
第二部分与第一部分形成鲜明对比，把一个测试坏味道的目录摆在你面前。除了描述测试代码中的可疑模式外，我们也给出了面对这些坏味道时的尝试方案。这些章节分为三个主题：令可读性退化的坏味道、暗示着潜在维护性梦魇的坏味道，以及带来信任危机的坏味道。第二部分的许多坏味道可以归为三大章节中的任何一个，但我们尝试根据其主要影响来归类。
第4章中的坏味道，主要侧重于过分不透明的测试意图或实现。我们涉及诸如模糊的断言、不恰当的抽象层次和测试代码的信息分散。
第5章中的坏味道会导致在办公室加班，因为要针对一个小的变更而没完没了地修改某个单元测试，或者为了一个小的变更要修改数百个测试。我们谈及了代码重复、测试代码中的逻辑和阐述触及文件系统的恐怖。我们也不会让缓慢的测试从眼皮底下溜过去，因为时间就是金钱。
第6章是测试坏味道目录的最后一部分，谈及一系列关于假设的陷阱。有些假设是由于测试代码中麻烦的注释，有些则是由于未能清楚地表达自己而带来的失败和不幸。
第三部分可以称为“高级话题”。然而并非如此，因为这里的话题与第一部分和第二部分并无关联。相反，这些是Java程序员在编写测试时随时可能碰到的话题。毕竟，无论是关于单元测试类的继承关系，还是用来编写测试的编程语言，或是构建设施运行测试的方式，几乎所有关于“优秀”单元测试的内容都依赖于上下文，所以对于造成某些程序员紧迫的话题，却无法打动另外一些人，这毫不奇怪。
第7章紧接第2章，探讨什么是可测的设计。先大致阐述了有用的原则，并澄清我们其实是在寻找模块化设计，然后我们学习了基本的可测性问题，它会导致代码不可测。该章最后给出一些简单的指南，来保证我们走在可测设计的康庄大道上。
第8章抛出一个突如其来的问题，如果我们用Java之外的编程语言来编写单元测试如何？Java虚拟机允许当今的程序员采用一些另类的编程语言，并将它们与普通Java代码集成到一起。
第9章回到现实的挑战，应对逐渐缓慢的构建及延迟的测试结果。我们从两方面同时寻找方案，一方面是测试代码，考虑如何令作为构建一部分的代码加速，另一方面是基础设施，考虑如何从更快的硬件或不同的硬件分配方式中获得额外的吸引力。
尽管JUnit的声望和地位已经是Java社区中事实上的单元测试框架，但并非所有的Java程序员都熟悉这个伟大的开源库。我们附加了两个附录，来帮助那些还没有体会到JUnit高级特性的强大之处的人。
附录A提供用JUnit编写测试的入门介绍，以及当你告诉JUnit运行测试时，JUnit如何来操作它们。浏览完这个附录后，你会更懂得编写测试，以及如何用JUnit的API来进行断言。
附录B旨在扩展JUnit的内置功能，于是深入地探讨其API。我们不会试图细致地涵盖JUnit的所有方面，而是带你浏览两个扩展JUnit的常见方式——规则和运行器——这个附录会展示一些内置规则，它们不仅有用，而且让你知道如何与自定义插件打交道。
代码规范
本书中的代码示例包含Java源代码和大量标记语言以及输出代码清单。以代码清单的方式来展示较长的代码。较短的代码就内联在文字中。我们经常会在文字中提到代码清单。许多较长的代码清单具有带编号的注解，它们会在文字中提及。
下载代码
Manning的网站www.manning.com/EffectiveUnitTesting上提供了本书的源代码打包下载。其中包含了本书的部分源代码，供你进一步钻研。
下载包中包括Apache Maven 2的POM文件，以及Maven(http://maven.apache.org)的安装使用说明，用来编译和运行示例。注意，下载包不包含各种依赖，而首次运行Maven时你需要连接互联网——Maven会从互联网下载所需依赖。随后，你就可以断开网络，离线地运行示例了。
代码示例用Java 6编写，你需要安装它以编译和运行示例。你可以从www.oracle.com下载合适的Java环境。（为了编译代码，你需要下载JDK，而不是JRE。）
我们还推荐安装合适的IDE。你可以下载安装最新版的Eclipse(www.eclipse.org)或其他主流工具比如IntelliJ IDEA(www.jetbrains.com)或NetBeans(www.netbeans.org)。只要你熟悉，这些工具都可以使用。
何去何从
这本书应当给你足够的洞察力，从而明显地提高你的单元测试能力。这是一条漫漫长路，肯定会有我们想不到或回答不了的问题。幸运的是，你会遇到很多同行，许多人会乐于分享和在线讨论测试代码的细微差别。
Manning建立了在线论坛，你可以和Manning图书的作者们交谈。本书作者就在Author Online论坛上，网址为www.manning.com/EffectiveUnitTesting。
在testdrivendevelopment和extremeprogramming Yahoo! Groups中，也有测试感染程序员的活跃社区。这些论坛是优秀的讨论区，不仅仅讨论单元测试。与此同时，或许你也能收获测试代码之外的一些新想法。
如果你寻找关于开发者测试的更加集中的论坛，那就去看看CodeRanch（http://www.coderanch.com）及其优秀的Testing论坛。那儿有一群可爱的牛人。
最重要的是，我建议你积极地与工作伙伴讨论测试代码。我自己的某些最佳见解就是通过让别人看我的代码才得出的。
计算机\软件测试
“一本出色、权威的指南。它可以帮助你提高生产力和开发效率。”
——Roger Cornejo，GlaxoSmithKline
“这本书改变了我对Java开发过程的看法，强烈推荐！”
——Phil Hanna，SAS Institute, Inc.
“这本书阐释了书写高质量代码的常识性方法。”
——Frank Crow Sr. Progeny Systems Corp.
“非常有用，即使你采用.NET编写代码。”
——J. Bourgeois，Freshly Coded
“如果单元测试是你的噩梦，那就来读这本书吧！”
——Franco Lombardo，Molteni Informatica
首先测试组件，然后将它们组装成完整的应用程序，这样你将会得到更优秀的软件。Java程序员已有几十年的经验来精心地设计测试，用于预测问题和识别代码中确定与未知的依赖，人们既能以隔离的方式测试组件，又能在完整的应用程序环境中进行测试。
本书教给Java程序员如何书写优秀的单元测试，做到简洁、富于表达力、有用并且可维护。除了提供清晰的解释和易懂的例子，本书还引入行为驱动开发和实例化需求等新兴技术。
2009年6月10日夜里，我收到来自Manning出版社Christina Rudloff的电子邮件，问我是否认识合适的人选，希望可以按照Roy Osherove的《.NET单元测试艺术》来写一本Java版的书。我跟她说，我来。
那是很久以前的事情了，而你现在看到的书与Roy的书已经大不相同了。我来解释一下。
项目一开始只是直接地从.NET翻译成Java，仅仅会为了符合技术平台、工具和读者的变化而重写一些必要之处。我完成了第1～3章，然后突然发现自己不只重写了一些段落，而是整个章节。那书不是我的调调；有时我不同意Roy的看法或者意见有偏差，有时我希望表达自己的想法，直截了当，大步前进。
最终，我决定从头开始。
很显然这不是一个翻译项目。这是全新的题目——一本帮助Java开发者改善测试的书，让人深入了解何为优秀的测试，以及避免落入各种陷阱。你仍然会在本书中以各种方式见到Roy的思想。例如，第二部分的章节标题就明显地从Roy那里借鉴而来，而第7章在很大程度上要感谢Roy的《.NET单元测试艺术》书中的相应部分。
本书是针对Java程序员的。但我并不想将想法束缚在本书中，因此即便模式目录中的所有代码例子都是用Java写的，我也尽量避免特定于语言的内容。书写优秀测试是个与语言无关的问题，即使你的大部分工作时间都花在另一种编程语言上，但是我也真心地推荐你带着思考来阅读本书。
与此同时，我不希望写成我喜欢的mock对象库或JUnit的一个教程。除了因为这些技术更新得太快以至于出版几个月就会过时，我也是希望写一本自己乐意去阅读的书。我喜欢专注的书籍，它不会强加我早就了解的一个测试框架或者用不到的mock对象库，而造成额外负担。基于这些原因，我尽量减少特定于技术的建议。虽然还是会有一些，但是我希望你知道我已经尽最大努力来减少它们了——只是用来有意义地谈论底层概念，那些概念我认为是书写、运行、维护和改善测试的基础。
我试着写了自己愿意读的一本书。我希望你也喜欢，而且最重要的是能将其中一些想法融入到你的实践中。
（芬）Lasse Koskela 著：暂无简介
申健 译：暂无简介
单元测试最初兴起于敏捷社区。1997年，设计模式四巨头之一Erich Gamma和极限编程发明人Kent Beck共同开发了JUnit，而JUnit框架在此之后又引领了xUnit家族的发展，深刻地影响了单元测试在各种编程语言中的普及。
随着敏捷开发大潮的流行，单元测试也成了现代软件开发中必不可少的工具之一。古人云，流水不腐，户枢不蠹。越来越多的程序员推崇自动化测试的理念，作为经济合理的回归测试手段，以适应迭代开发的需要。然而有些时候，这些测试对生产力并无明显改善，人们盲目地追求测试覆盖率，却忽视了测试代码的质量，各种无效单元测试反而带来了沉重的维护负担。
2013年年初，一位远在新加坡的印度朋友Ram就推荐我看过本书的英文版，当时完整读了一遍，觉得该书深入浅出，覆盖了很多关于编写优秀单元测试的内容，而且总结得很有条理。没想到的是，2013年下半年，出版社的编辑找到我说有一本书愿不愿翻译，没想到正是本书！既然有缘，当时就答应了下来。
本以为半年可以完成翻译，却没想到过去的12个月里生活和工作出现各种变化与惊喜，于是翻译工作一拖再拖，进展不快。
2014年6月Scrum Gathering大会在上海召开，作为话题演讲的总制作人和大会讲师，原想书能尽快出版，就可以带去一些回馈社区，只可惜没能实现，又让朋友们多等了几个月。
目前，我从事敏捷教练和培训的工作，同时通过动手实践仍在不断提高自己的编程水平。希望借此机会，将我过去几年的敏捷实践经验分享给更多人。
个人喜欢和敏捷社区的软件匠友动手切磋，一起编写高质量代码，另外在讲授CSD（认证Scrum开发者或称敏捷技术实践）课程时，也经常会接触来自不同行业的软件开发者。在这个过程中，我们发现，审美之前有必要先学审丑。好的编码模式各有千秋，能抓到老鼠的就是好猫。然而，坏的模式却是有限的。
本书作者Lasse在敏捷技术实践领域一直走在前沿，在TDD和单元测试领域颇有研究。他将本书分为三部分，首先分析了编写测试的目的，以及优秀测试的特征，然后是本书的核心部分，从三个角度一一阐述了测试的坏味道。此外，本书还介绍了测试替身的概念与用法，如何用另类JVM语言为Java代码编写测试，如何提高代码的可测性，以及如何加速测试和构建的速度，从而加快反馈的速度。
翻译是个耗时的差事，时间投入与经济回报不成比例。于是，有人不禁问你为什么还要坚持翻译。在我看来，既然自己从社区中获得很多养分，也就有义务将更多丰厚的知识和实践经验分享给大家。同样的原因，几年来我也一直坚持参与组织各种社区活动，回馈社区。
作为译者，因为能力水平有限，难免会有疏漏，在此恳请读者见谅，并给予批评指正。
在本书的翻译过程中得到了多位软件匠友大力协助，非常感谢：尹哲、伍斌、王洪亮（排名不分先后）。
感谢所有关心和鼓励我的人。特别是我的家人，在那些挑灯奋战的夜晚里默默地给予着支持。
今宵梦霓虹 明空浩荡
残思追穹方 月已西徜
译者序
序言
前言
致谢
第一部分 基础
第1章 优秀测试的承诺 2
1.1 国情咨文：编写更好的测试 3
1.2 测试的价值 3
1.2.1 生产力的因素 6
1.2.2 设计潜力的曲线 8
1.3 测试作为设计工具 9
1.3.1 测试驱动开发 9
1.3.2 行为驱动开发 11
1.4 小结 12
第2章 寻求优秀 13
2.1 可读的代码才是可维护的代码 14
2.2 结构有助于理解事物 16
2.3 如果测试了错误的东西就不好了 17
2.4 独立的测试易于单独运行 18
2.5 可靠的测试才是可靠的 21
2.6 每个行业都有其工具而测试也不例外 22
2.7 小结 23
第3章 测试替身 24
3.1 测试替身的威力 25
3.1.1 隔离被测代码 26
3.1.2 加速执行测试 27
3.1.3 使执行变得确定 27
3.1.4 模拟特殊情况 28
3.1.5 暴露隐藏的信息 29
3.2 测试替身的类型 30
3.2.1 测试桩通常是短小的 30
3.2.2 伪造对象做事不产生副作用 31
3.2.3 测试间谍偷取秘密 32
3.2.4 模拟对象反对惊喜 34
3.3 使用测试替身的指南 35
3.3.1 为测试挑选合适的替身 35
3.3.2 准备、执行、断言 36
3.3.3 检查行为，而非实现 37
3.3.4 挑选你的工具 38
3.3.5 注入依赖 39
3.4 小结 39
第二部分 目录
第4章 可读性 42
4.1 基本断言 43
4.1.1 示例 43
4.1.2 该对它做点儿什么 44
4.1.3 小结 45
4.2 过度断言 46
4.2.1 示例 46
4.2.2 该对它做点儿什么 48
4.2.3 小结 50
4.3 按位断言 50
4.3.1 示例 50
4.3.2 该对它做点儿什么 51
4.3.3 小结 51
4.4 附加细节 52
4.4.1 示例 52
4.4.2 该对它做点儿什么 53
4.4.3 小结 54
4.5 人格分裂 55
4.5.1 示例 55
4.5.2 该对它做点儿什么 56
4.5.3 小结 58
4.6 逻辑分割 59
4.6.1 示例 59
4.6.2 该对它做点儿什么 61
4.6.3 小结 63
4.7 魔法数字 64
4.7.1 示例 64
4.7.2 该对它做点儿什么 64
4.7.3 小结 65
4.8 冗长安装 65
4.8.1 示例 66
4.8.2 该对它做点儿什么 67
4.8.3 小结 68
4.9 过分保护 68
4.9.1 示例 69
4.9.2 该对它做点儿什么 69
4.9.3 小结 70
4.10 总结 70
第5章 可维护性 71
5.1 重复 72
5.1.1 示例 72
5.1.2 该对它做点儿什么 73
5.1.3 小结 75
5.2 条件逻辑 75
5.2.1 示例 76
5.2.2 该对它做点儿什么 76
5.2.3 小结 77
5.3 脆弱的测试 78
5.3.1 示例 78
5.3.2 该对它做点儿什么 79
5.3.3 小结 80
5.4 残缺的文件路径 80
5.4.1 示例 81
5.4.2 该对它做点儿什么 81
5.4.3 小结 83
5.5 永久的临时文件 83
5.5.1 示例 84
5.5.2 该对它做点儿什么 85
5.5.3 小结 86
5.6 沉睡的蜗牛 86
5.6.1 示例 87
5.6.2 该对它做点儿什么 88
5.6.3 小结 89
5.7 像素完美 89
5.7.1 示例 89
5.7.2 该对它做点儿什么 90
5.7.3 小结 93
5.8 参数化混乱 94
5.8.1 示例 95
5.8.2 该对它做点儿什么 98
5.8.3 小结 99
5.9 方法间缺乏内聚 100
5.9.1 示例 100
5.9.2 该对它做点儿什么 101
5.9.3 小结 104
5.10 总结 104
第6章 可信赖 106
6.1 注释掉的测试 107
6.1.1 示例 107
6.1.2 该对它做点儿什么 108
6.1.3 小结 108
6.2 歧义注释 109
6.2.1 示例 109
6.2.2 该对它做点儿什么 110
6.2.3 小结 111
6.3 永不失败的测试 111
6.3.1 示例 112
6.3.2 该对它做点儿什么 112
6.3.3 小结 113
6.4 轻率承诺 113
6.4.1 示例 114
6.4.2 该对它做点儿什么 115
6.4.3 小结 116
6.5 降低期望 117
6.5.1 示例 117
6.5.2 该对它做点儿什么 118
6.5.3 小结 118
6.6 平台偏见 119
6.6.1 示例 119
6.6.2 该对它做点儿什么 120
6.6.3 小结 121
6.7 有条件的测试 122
6.7.1 示例 122
6.7.2 该对它做点儿什么 123
6.7.3 小结 124
6.8 总结 124
第三部分 消遣
第7章 可测的设计 126
7.1 什么是可测的设计 126
7.1.1 模块化设计 127
7.1.2 SOLID设计原则 128
7.1.3 上下文中的模块化设计 129
7.1.4 以测试驱动出模块化设计 130
7.2 可测性的问题 130
7.2.1 无法实例化某个类 130
7.2.2 无法调用某个方法 131
7.2.3 无法观察到输出 131
7.2.4 无法替换某个协作者 131
7.2.5 无法覆盖某个方法 132
7.3 可测的设计的指南 132
7.3.1 避免复杂的私有方法 133
7.3.2 避免final方法 133
7.3.3 避免static方法 134
7.3.4 使用new时要当心 134
7.3.5 避免在构造函数中包含逻辑 135
7.3.6 避免单例 137
7.3.7 组合优于继承 138
7.3.8 封装外部库 138
7.3.9 避免服务查找 139
7.4 小结 140
第8章 用其他JVM语言来编写测试 142
8.1 混合使用JVM语言的前提 142
8.1.1 通用收益 143
8.1.2 编写测试 144
8.2 用Groovy来编写测试 146
8.2.1 简化的测试setup 146
8.2.2 Groovy式的JUnit 4测试 148
8.3 BDD工具的表达力 149
8.3.1 用easyb写Groovy需求说明 149
8.3.2 Spock Framework：编写更具表达力测试的激素 150
8.3.3 Spock Framework的测试替身也打了激素 152
8.4 小结 153
第9章 加速执行测试 155
9.1 追求速度 156
9.1.1 对速度的需要 156
9.1.2 进入状况 156
9.1.3 对构建进行性能分析 157
9.1.4 对测试进行性能分析 160
9.2 令测试代码加速 162
9.2.1 别睡觉，除非你累了 163
9.2.2 当心膨胀的基类 163
9.2.3 当心冗余的setup与teardown 165
9.2.4 挑剔地添加新测试 166
9.2.5 保持本地运行，保持快速 167
9.2.6 抵御访问数据库的诱惑 168
9.2.7 没有比文件I/O更慢的I/O了 169
9.3 令构建加速 171
9.3.1 RAM磁盘带来更快的I/O 172
9.3.2 并行构建 173
9.3.3 改换为高性能CPU 177
9.3.4 分布式构建 179
9.4 小结 183
附录A JUnit入门 185
附录B 扩展JUnit 192
