单元测试的艺术(第2版)

. 第2版新增：

受限与不受限的隔离框架及其工作原理

隔离框架的特征及Typemock等框架的内部工作机制

更多实施单元测试的可用技术

调优示例代码的设计（避免使用属性设置方法，转而使用构造函数注入）

点到为止，探讨SOLID原则

构建自动化及测试模式

对设计与可测试性的新认识

更新工具与框架（附录A）

2.3.2　加载解决方案　　22
2.3.3　在代码中使用NUnit属性　　24
2.4　编写第一个测试　　25
2.4.1　Assert类　　25
2.4.2　用NUnit运行第一个测试　　26
2.4.3　添加正检验　　27
2.4.4　从红到绿：测试成功　　28
2.4.5　测试代码格式　　28
2.5　使用参数重构测试　　28
2.6　更多NUnit属性　　30
2.6.1　setup和teardown　　30
2.6.2　检验预期的异常　　33
2.6.3　忽略测试　　35
2.6.4　NUnit的方法语法　　36
2.6.5　设置测试类别　　37
2.7　测试系统状态的改变而非返回值　　37
2.8　小结　　41
第二部分　核心技术
第3章　使用存根破除依赖　　44
3.1　存根简介　　44
3.2　发现LogAn中对文件系统的依赖　　45
3.3　如何使测试LogAnalyzer变得容易　　46
3.4　重构代码设计以提高可测试性　　48
3.4.1　抽取接口使底层实现可替换　　49
3.4.2　依赖注入：在被测试单元中注入一个伪实现　　51
3.4.3　在构造函数层注入一个伪对象（构造函数注入）　　51
3.4.4　用伪对象模拟异常　　55
3.4.5　用属性get或set注入伪对象　　56
3.4.6　在方法调用前注入伪对象　　57
3.5　重构技术变种　　63
3.6　克服封装问题　　65
3.6.1　使用internal和[InternalsVisibleTo]　　65
3.6.2　使用[Conditional]属性　　66
3.6.3　使用#if和#endif进行条件编译　　66
3.7　小结　　67
第4章　使用模拟对象进行交互测试　　68
4.1　基于值的测试、基于状态的测试和交互测试　　68
4.2　模拟对象和存根的区别　　70
4.3　手工模拟对象的简单示例　　71
4.4　同时使用模拟对象和存根　　73
4.5　每个测试一个模拟对象　　78
4.6　伪对象链：用存根生成模拟对象或其他存根　　78
4.7　手工模拟对象和存根的问题　　79
4.8　小结　　80
第5章　隔离（模拟）框架　　81
5.1　为什么要使用隔离框架　　81
5.2　动态生成伪对象　　83
5.2.1　在测试中使用NSubstitute　　83
5.2.2　用动态伪对象替换手工伪对象　　84
5.3　模拟值　　86
5.4　测试事件相关的活动　　92
5.4.1　测试事件监听者　　92
5.4.2　测试事件是否触发　　93
5.5　现有的.NET隔离框架　　94
5.6　隔离框架的优缺点　　95
5.6.1　使用隔离框架时应避开的陷阱　　96
5.6.2　测试代码不可读　　96
5.6.3　验证错误的事情　　96
5.6.4　一个测试多个模拟对象　　96
5.6.5　过度指定测试　　97
5.7　小结　　97
第6章　深入了解隔离框架　　99
6.1　受限框架及不受限框架　　99
6.1.1　受限框架　　99
6.1.2　不受限框架　　100
6.1.3　基于探查器的不受限框架如何工作　　101
6.2　优秀隔离框架的价值　　103
6.3　支持适应未来和可用性的功能　　103
6.3.1　递归伪对象　　104
6.3.2　默认忽略参数　　104
6.3.3　泛伪造　　105
6.3.4　伪对象的非严格行为　　105
6.3.5　非严格模拟对象　　106
6.4　隔离框架设计反模式　　106
6.4.1　概念混淆　　106
6.4.2　录制和重放　　107
6.4.3　粘性行为　　109
6.4.4　复杂语法　　109
6.5　小结　　109
第三部分　测试代码
第7章　测试层次和组织　　112
7.1　运行自动化测试的自动化构建　　112
7.1.1　构建脚本结构　　113
7.1.2　触发构建和集成　　115
7.2　基于速度和类型布局测试　　116
7.2.1　分离集成测试和单元测试的人为因素　　117
7.2.2　绿色安全区　　117
7.3　确保测试是源代码管理的一部分　　118
7.4　将测试类映射到被测试代码　　118
7.4.1　将测试映射到项目　　118
7.4.2　将测试映射到类　　118
7.4.3　将测试映射到具体的工作单元入口　　119
7.5　注入横切关注点　　120
7.6　为应用程序构建测试API　　122
7.6.1　使用测试类继承模式　　122
7.6.2　创建测试工具类和方法　　133
7.6.3　把你的API介绍给开发人员　　134
7.7　小结　　134
第8章　优秀单元测试的支柱　　136
8.1　编写可靠的测试　　136
8.1.1　决定何时删除或修改测试　　137
8.1.2　避免测试中的逻辑　　140
8.1.3　只测试一个关注点　　142
8.1.4　把单元测试和集成测试分开　　143
8.1.5　用代码审查确保代码覆盖率　　143
8.2　编写可维护的测试　　144
8.2.1　测试私有或受保护的方法　　145
8.2.2　去除重复代码　　146
8.2.3　以可维护的方式使用setup方法　　149
8.2.4　实施测试隔离　　151
8.2.5　避免对不同关注点多次断言　　156
8.2.6　对象比较　　158
8.2.7　避免过度指定　　160
8.3　编写可读的测试　　162
8.3.1　单元测试命名　　162
8.3.2　变量命名　　163
8.3.3　有意义的断言　　164
8.3.4　断言和操作分离　　165
8.3.5　setup和teardown　　165
8.4　小结　　166
第四部分　设计和流程
第9章　在组织中引入单元测试　　168
9.1　逐步成为变革的倡导者　　168
9.1.1　准备好面对质疑　　169
9.1.2　说服组织内成员：支持者和反对者　　169
9.1.3　找到可能的切入点　　169
9.2　成功之道　　171
9.2.1　游击式实现（自下而上）　　171
9.2.2　说服高层（自上而下）　　171
9.2.3　引入外援　　172
9.2.4　使进度可见　　172
9.2.5　设定具体目标　　173
9.2.6　应对障碍　　175
9.3　失败原因　　175
9.3.1　缺少驱动力　　175
9.3.2　缺乏政策支持　　175
9.3.3　不好的实现和第一印象　　176
9.3.4　缺少团队支持　　176
9.4　影响因素　　176
9.5　质疑和回答　　177
9.5.1　单元测试会给现有流程增加多少时间　　178
9.5.2　单元测试是否会抢了QA饭碗　　179
9.5.3　证明单元测试确实有效的方法　　179
9.5.4　单元测试有用的证据　　180
9.5.5　QA部门还是能找到缺陷的原因　　180
9.5.6　我们有大量没有测试的代码：应该从哪里开始　　181
9.5.7　我们使用多种编程语言：单元测试是否可行　　181
9.5.8　软硬件结合的开发　　181
9.5.9　确保测试中没有缺陷的方法　　181
9.5.10　我的代码已经调试通过了，但还需要测试的原因　　182
9.5.11　驱动开发测试的必要性　　182
9.6　小结　　182
第10章　遗留代码　　183
10.1　从哪里开始增加测试　　183
10.2　决定选择策略　　185
10.2.1　先易后难策略的优缺点　　185
10.2.2　先难后易策略的优缺点　　186
10.3　在重构前编写集成测试　　186
10.4　遗留代码单元测试的重要工具　　187
10.4.1　使用不受限的隔离框架轻松隔离依赖项　　187
10.4.2　使用JMockit测试Java遗留代码　　189
10.4.3　重构Java代码时使用Vise　　190
10.4.4　重构前使用验收测试　　191
10.4.5　阅读Michael Feathers关于遗留代码的书　　192
10.4.6　使用NDepend调查产品代码　　192
10.4.7　使用ReSharper浏览和重构产品代码　　192
10.4.8　使用Simian和TeamCity发现重复代码（和缺陷）　　193
10.5　小结　　193
第11章　设计与可测试性　　194
11.1　为什么在设计时要关心可测试性　　194
11.2　可测试性的设计目标　　195
11.2.1　默认情况下将方法设置为虚拟方法　　195
11.2.2　使用基于接口的设计　　196
11.2.3　默认情况下将类设置为非密封的　　196
11.2.4　避免在包含逻辑的方法内初始化具体类　　197
11.2.5　避免直接调用静态方法　　197
11.2.6　避免在构造函数和静态构造函数中包含逻辑代码　　197
11.2.7　把单例逻辑和单例持有者分开　　198
11.3　可测试性设计的利弊　　199
11.3.1　工作量　　199
11.3.2　复杂度　　200
11.3.3　泄露敏感知识产权　　200
11.3.4　有时无法实现　　200
11.4　可测试性设计的替代方法　　200
11.5　难以测试的设计示例　　202
11.6　小结　　205
11.7　更多资源　　206
附录A　工具和框架　　208

.　　被调用的公共方法返回一个值（一个返回值不为空的函数）。
　　在方法调用的前后，系统的状态或行为有可见的变化，这种变化无需查询私有状态即可
　　判断。（例如：一个以前不存在的用户可以登入系统，或者一个状态机系统的属性发生
　　变化。）
　　调用了一个不受测试控制的第三方系统，这个第三方系统不返回任何值，或者返回值都
　　被忽略。（例如：调用一个第三方日志系统，这个系统不是你编写的，而且你也没有源
　　代码。）
　　对于我来说，工作单元这个概念意味着一个单元既可以小到只包含一个方法，也可以大到包括实现某个功能的多个类和函数。
　　你也许觉得被测试的工作单元应该尽可能的小。我以前也这么认为，现在却不这么看。如果你创建的工作单元更大，而且它的最终结果对这个接口的用户可见度更高，那么我相信你的测试会更容易维护。如果你试图把工作单元缩到最小，最后会不得不伪造一堆东西，这些东西并不是使用公共API的真实最终结果，而是生成结果过程中的一些中间状态。我会在之后关于过度指定的部分（大部分内容在第8章）对此做更多的解释。
　　定义更新1.1一个单元测试是一段代码，这段代码调用一个工作单元，并检验该工作单元的一个具体的最终结果。如果关于这个最终结果的假设是错误的，单元测试就失败了。一个单元测试的范围可以小到一个方法，大到多个类。
　　不管你使用哪种编程语言，要定义单元测试，最困难的就是定义“优秀的”单元测试。
　　1.1.1编写优秀单元测试的重要性
　　要理解单元测试，能理解什么是工作单元还不够。
　　大部分尝试对自己的代码进行单元测试的人要么在某个阶段放弃了，要么并没有真正执行单元测试。他们或者依靠在产品生命周期后期执行的系统测试和集成测试来发现问题，或者改用手工方式，使用定制的测试应用程序或者通过最终产品调用代码来进行测试。
　　编写差劲的单元测试是没有意义的，除非你正在学习如何编写单元测试，这些差劲的测试是你初次练习的产物。如果你不加鉴别地胡乱编写单元测试，那还不如干脆不写，至少还能免除日后维护和时间安排的麻烦。通过定义什么是优秀的单元测试，你可以确保自己在开始编写单元测试时有正确的目标。
　　要理解什么是优秀的单元测试，你需要了解开发人员在测试的时候都做些什么。
　　那么，如何确保代码今天还能工作呢？
　　1.1.2我们都写过（某种）单元测试
　　不要惊讶，你已经自己进行过某种程度的单元测试。你见过提交代码前不做测试的开发人员吗？是啊，我也没见过。
　　也许你是用一个控制台程序来调用一个类或组件的各种方法，也许是特意创建WinForm或者Web Form的用户界面来检查这个类或组件的功能，也许干脆是在实际应用程序的用户界面上手工执行各种操作。但最终的结果都是让你能在一定程度上确信代码工作正常，可以移交给其他人。
　　图1-1展示了大多数开发人员如何测试他们的代码。具体的用户界面可能会不同，但是模式通常是一样的：使用一个手工的外部工具反复进行检验，或者运行整个应用程序，手工验证它的行为。
　　图1-1在传统测试中，开发人员使用一个图形用户界面（GUI）触发
　　要测试的类的某个行为，然后检验结果
　　这些测试也许很有用，而且可能也很接近传统定义的单元测试，但是它们和我在本书中要定义的优秀的单元测试还有很大的区别。说到这里，我们又回到了一个开发人员在定义优秀的单元测试的特质时要面对的第一个问题，也是最重要的问题：什么是单元测试，什么不是单元测试？
　　1.2优秀单元测试的特性
　　一个单元测试应当具有如下特征：
　　它应该是自动化的，可重复执行；
　　它应该很容易实现；
　　它应该第二天还有意义；
　　任何人都应该能一键运行它；
　　它应该运行速度很快；
　　它的结果应该是稳定的（如果运行之间没有进行修改的话，多次运行一个测试应该总是返回同样的结果）；
　　它应该能完全控制被测试的单元；
　　它应该是完全隔离的（独立于其他测试的运行）；
　　如果它失败了，我们应该很容易发现什么是期待的结果，进而定位问题所在。
　　很多人把进行软件测试的行为和单元测试的概念混为一谈。要澄清这个误解，你首先应该回顾自己以前写过的测试，问自己如下问题。
　　我两周前写的一个单元测试，今天还能运行并得到结果吗？几个月前写的呢？几年前写的呢？
　　我两个月前写的单元测试，我团队里任何一个人都能运行它们并得到结果吗？
　　我能在几分钟内跑完我写过的所有单元测试吗？
　　我能一键运行我写过的所有单元测试吗？
　　我能在几分钟内写出一个基本的测试吗？
　　如果你对以上问题中的任何一个回答“不能”，那很有可能实施的并不是单元测试。如果你实施的是单元测试，那对所有那些问题的回答都应该是“能”。当然你做的肯定是某种测试，而且这种测试也和单元测试一样重要，但是和单元测试相比，这种测试具有一些缺点。
　　你可能会问：“那我以前做的都是什么测试呢？”你做的实际上是集成测试。
　　1.3集成测试
　　任何测试，如果它运行速度不快，结果不稳定，或者要用到被测试单元的一个或多个真实依赖物，我就认为它是集成测试。例如，如果一个测试要使用真实的系统时间，真实的文件系统，或者一个真实的数据库，那这个测试就进入了集成测试的领域。
　　例如，如果一个测试不能控制系统时间，在代码中使用了当前时间DateTime.Now，那么每次测试执行使用的都是不同的时间，因此每次测试本质上都是不同的，那么这个测试就不稳定了。
　　这种测试本身并不是一件坏事。我认为集成测试和单元测试具有同等重要的地位，但是这两种测试应该彼此分开，以营造一种“绿色安全区”的感觉。这一点我会在本书后面的章节讨论。
　　如果一个测试使用真实的数据库，那么和那些只使用内存中的伪数据的测试相比，这种测试的行为痕迹更难以消除，从这个意义上说它就不是只在内存中运行了。这种测试的运行时间也会更长，这个问题也是无法控制的。单元测试运行应该很快。集成测试通常会慢很多。如果你有成百上千个测试的话，半秒钟都是至关重要的。
　　集成测试还可能带来另外一个问题：一次测试的东西太多。
　　如果汽车坏了该怎么办？先不说怎么修好它，你怎么找到问题出在哪呢？一个汽车的发动机由许多子系统组成，这些子系统协同工作，每个子系统都依靠其他的子系统的帮助产生最终的结果：一辆飞驰的汽车。如果汽车不动了，问题可能出在这些子系统中的任何一个，或者多个。这些子系统（或层次）的集成使得汽车能够工作。当汽车上路时，你可以把它能否开动看成是对这些部件的一个终极集成测试。如果这个测试失败了，那所有的部件就都失败了；如果这个测试成功了，那所有的部件也就都成功了。
　　软件也是同样的道理。大部分开发人员是通过用户界面的最终功能来测试软件的功能。单击一个按钮会触发一系列的事件，类和组件协同工作产生最终的结果。如果测试失败了，所有这些软件组件作为一个整体就失败了，而且很难找到到底是什么导致了整体操作的失败（参见图1-2）。
　　图1-2集成测试中可能有很多失败点。所有的单元要一起工作，而每个单元都有可能出错，因此找到缺陷的根源就更加困难
　　正如Bill Hetzel在The Complete Guide to Software Testing（Wiley，1993）一书中定义的，集成测试是“一个循序渐进的测试，软硬件相结合并进行测试直到整个系统集成在一起”。但是很多人每天做的不是系统集成测试，而是开发和单元测试， 这个定义并不太适用。
　　这里有一个更好的集成测试定义。
　　定义集成测试是对一个工作单元进行的测试，这个测试对被测试的工作单元没
　　有完全的控制，并使用该单元的一个或多个真实依赖物，例如时间、网络、数据库、线程或随机数产生器等。
　　总的来说，集成测试会使用真实依赖物，而单元测试则把被测试单元和其依赖物隔离开，以保证单元测试结果高度稳定，还可以轻易控制和模拟被测试单元行为的任何方面。
　　1.2节中列出的问题可以帮助你认识到集成测试的一些缺点。我们接下来要定义期望在优秀的单元测试中看到的特质。
　　与自动化单元测试相比，非自动化集成测试的缺点
　　让我们把1.2节中的问题同样应用在集成测试上，同时思考在真实世界中使用单元测试的目的。
　　我两周前写的一个单元测试，今天还能运行并得到结果吗？几个月前写的呢？几年前写的呢？
　　如果回答是“不能”，那你怎么知道自己是不是已经破坏了以前实现的某个功能？在应用程序的生命周期中，代码经常会变化。如果在修改代码之后，你不能（或者不愿意）对之前所有的功能进行测试，就有可能破坏了某个功能而毫不知情。我把这种情况称为“偶然引入缺陷”。在软件项目快结束时，开发人员承受着压力修复已有的缺陷，“偶然引入缺陷”的情况会经常发生。有时开发人员会在修复旧缺陷的时候无意间引入新缺陷。如果在破坏功能后三分钟内就能发现问题，那该多好啊！在本书后面的章节中，你会了解如何做到这一点。
　　定义回归是以前运行良好但是现在不工作的一个或多个工作单元。
　　我两个月前写的单元测试，团队里任何一个人都能运行它们并得到结果吗？
　　这个问题和上一个属于一个范畴，但比上一个问题要求更高。当你做改动时，需要保证自己不会破坏别人的代码。许多开发人员都害怕修改以前系统中的遗留代码，就是担心不知道有什么别的代码依赖他们要改动的部分。简言之，他们不知道系统修改后的状态是否稳定。
　　应用程序是不是还正常工作是很令人担心的，尤其代码还不是你自己写的。如果知道自己不会破坏任何功能，你就比较有信心接手不太熟悉的代码了，因为有单元测试这个安全网。
　　优秀的单元测试可被任何人访问和运行。
　　定义遗留代码在维基百科中定义为“与一个不再受支持或继续生产的操作系统，或其他计算机技术相关的源代码”，但是很多公司把任何比当前维护的应用更老旧的版本都称为遗留代码。这个词经常用来指代那些难以使用，难以测试，通常也更难以阅读的代码。
　　有一个客户曾经以一种很实际的方式定义遗留代码：“能运行的代码”。很多人喜欢把遗留代码定义为“没有测试的代码”。Michael Feathers在《修改代码的艺术》（Prentice Hall，2004）中把“没有测试的代码”作为遗留代码的正式定义，在阅读本书时我们也需要对此定义加以考虑。
　　我能在几分钟内跑完我写过的所有单元测试吗？
　　如果你不能很快运行完测试（几秒钟完成要好于几分钟完成），就不会经常运行它们（每天或者每周，有时甚至每月运行）。问题是，如果修改代码，你需要尽早得到反馈，好知道自己是不是破坏了什么功能。运行测试的时间间隔越长，你对系统做未测试的修改越多，出现问题的时候需要找寻缺陷的地方就越多。
　　优秀的测试需要能够快速运行。
　　我能一键运行我写过的所有单元测试吗？
　　如果不能，那可能意味着你需要对运行测试的机器进行配置，让测试能够正确运行（比如设置数据库的连接字符串），或者单元测试不是完全自动化的。如果不能完全自动化单元测试，你很可能会避免重复运行这些测试，团队里的其他人也一样。
　　没有人喜欢费工夫配置然后运行测试，而结果只是为了保证系统还能运行。开发人员有着更重要的任务，比如在系统中增加更多功能。
　　优秀的测试应该无需修改就能运行，不需要手工配置。
　　我能在几分钟内写出一个基本的测试吗？
　　辨别集成测试的一个最简单方法就是：集成测试需要花时间进行正确的准备和实施，不能直接执行。编写集成测试需要花费时间，因为它涉及内部，有时还有外部的依赖。（数据库可以看做外部依赖。）如果不对测试进行自动化，依赖就不是一个太大的问题，但是你也就失去了享受自动化测试所有好处的机会。编写测试的难度越高，你编写更多测试的可能性就越小，对所担心的“大问题”之外的东西也会关注越少。单元测试的一个特点就是会测试可能出问题的每一处细节，而不只是关注大问题。人们常常会惊讶：有很多缺陷正是在他们认为简单正确的代码里找到的。
　　当你只关注大的测试时，测试的逻辑覆盖率就会比较低，代码中核心逻辑的很多部分不会测到（虽然你可能覆盖到了较多的组件），这样就可能会出现没有考虑到的缺陷。
　　一旦找到了想用来测试具体对象模型的模式，你就应该能很快地轻松编写出优秀的测试。一个小小的警告：对一个以前没有做过单元测试的对象模型，即便是有经验的单元测试人员，也需要花30分钟或者更长时间才能写出第一个单元测试。这种摸索工作是难免的，也是预料之中的。对这个对象模型的第二个以及之后的测试应该很容易就能完成了。
　　到现在，我已经解释了什么测试不是单元测试，以及有用的测试应具有什么特征。基于这些，现在我可以开始回答这一章提出的主要问题了：什么是优秀的单元测试？
　　1.4什么是优秀的单元测试
　　在讨论了单元测试应该具有的重要属性之后，我来给出单元测试的最终定义。
　　定义最终更新1.2一个单元测试是一段自动化的代码，这段代码调用被测试的工作单元，之后对这个单元的单个最终结果的某些假设进行检验。单元测试几乎都是用单元测试框架编写的。单元测试容易编写，能快速运行。单元测试可靠、可读，并且可维护。只要产品代码不发生变化，单元测试的结果是稳定的。
　　这个定义看起来的确很难实现，尤其是考虑到有很多开发人员的单元测试都做得很糟糕。我们需要认真审视一下，到现在为止，作为开发人员是如何实施测试的，并和我们希望的方式做个比较。（第8章将讨论可靠、可读以及可维护的测试。）
　　在本书的前一版本中，我对单元测试的定义略有不同。我在前一版本中把单元测试定义为“只对控制流代码运行”，但现在认为这不正确。没有逻辑的代码通常用作工作单元的一部分。即便是没有逻辑的属性也会在工作单元中使用，因此测试不需要特别针对它们。
　　定义控制流代码是包含某种逻辑的代码段，无论其规模大小。控制流代码包含
　　下面列举的一种或多种语句：if语句；loop、switch或case语句；计算；或其他任何类型的决策代码。
　　说到通常不包含任何逻辑，因此不需要特别进行测试的代码，属性（Java中的获取方法/设置方法）是个很好的例子。这种代码通常会用在你要测试的工作单元中，但是没必要直接测试它。但是要小心：一旦你在一个属性中加入了任何检验逻辑，就需要确保这个逻辑在测试中覆盖。
　　在下一节中，我们要介绍一个完全用代码实现的简单的单元测试，这个测试不使用任何单元测试框架。（我们会在第2章介绍单元测试框架。）
　　1.5一个简单的单元测试范例
　　不用测试框架我们也可以编写一个自动化的单元测试。实际上，因为开发人员更习惯于将测试自动化，他们中很多人在知道有测试框架之前，就已经在做自动化的单元测试了。在本节中，我会展示没有框架是怎么编写自动化单元测试的，你可以把这个例子和第2章中使用框架的例子进行对比。
　　假设有一个类SimpleParser（如代码清单1-1所示）需要测试。这个类有一个方法ParseAndSum。ParseAndSum的输入是由零个或多个逗号分隔的数值组成的字符串。如果输入字符串不包含数值，方法返回0。如果输入包含单个数值，方法返回这个数值的int值。如果输入包含多个数值，方法把所有数值相加，返回总数（但是现在这段代码只能处理零个或一个数值）。是的，我知道代码里的else语句不是必需的，但是我们也不用这么死板吧。我倒觉得这个else语句增加了代码的可读性。
　　代码清单1-1要测试的简单解析类
　　你可以创建一个简单的控制台应用项目，引用包含这个类的程序集，然后写一个如下面代码清单所示的方法SimpleParserTests。这个测试方法调用这个产品类（即被测试的类），然后检验调用的返回值。如果返回值和预期值不同，测试方法就会把结果输出到控制台。这个测试方法也会捕捉任何异常，并且把异常信息输出到控制台。
　　代码清单1-2测试SimpleParser类的一段简单代码
　　接下来，你可以在这个项目的控制台程序里，使用方法Main调用你写的测试，具体请参见下面的代码清单。方法Main在这里用作一个简单的测试运行器，逐个调用测试，让测试结果输出到控制台。因为这是一个可执行程序，它可以无需人工干预自己运行（假设这些测试不会弹出任何交互式的用户对话框）。
　　代码清单1-3通过一个简单的控制台程序运行测试代码
　　捕获发生的任何异常并输出到控制台是测试方法的职责，这样异常就不会干扰其后方法的运行。之后随着在项目中加入更多的测试，你可以在方法Main中增加更多的方法调用。每个测试各自负责把问题输出（如果有问题的话）到控制台屏幕。
　　显然，这是一种随意的测试编写方法。如果要编写多个这样的测试，你可能希望有一个通用的ShowProblem方法，所有的测试都可以用这个方法一致地格式化错误信息。你也可以添加专门的辅助方法，辅助检查空对象、空字符串等情况，避免在多个测试中重复书写同样的冗长代码。
　　下面的代码清单展示了使用一个较为通用的ShowProblem方法的测试代码。
　　代码清单1-4使用一个较为通用的ShowProblem方法
　　单元测试框架可以像上面的示例一样创建更为通用的辅助方法，使测试更容易编写。我会在第2章讨论测试框架的这个功能。在那之前，我们来看“如何编写单元测试”之外的一个重要问题，那就是“在开发过程中应该何时编写单元测试”。这就是测试驱动开发要解决的问题。
　　1.6测试驱动开发
　　一旦了解了如何使用一个单元测试框架编写结构化、可维护和可靠的测试，下一个问题就是什么时候编写测试。很多人觉得为软件编写单元测试的最佳时机是软件编码完成以后，但是越来越多的人选择在产品代码编写之前写单元测试。这种方法称为测试优先或是测试驱动开发（Test-Driven Development，TDD）。
　　注意 对于测试驱动开发的具体含义，人们有很多不同的观点。有人说测试驱动开发是测试优先开发，有人说测试驱动就是进行大量的测试。有人说测试驱动开发是一种代码设计方法，其他人则觉得只有使用某些设计时，测试驱动开发才成为一种驱动代码行为的方法。要更全面地了解人们对TDD的观点，请参考我的博客文章“TDD的各种含义”（The various meanings of TDD，参见http://osherove.com/blog/2007/10/8/the-various-meanings-of-tdd.html）。在本书中，TDD意指测试优先开发，设计仅作为这项技术中的次要方面（本书中不讨论设计）。
　　图1-3和图1-4展示了传统编码方式和TDD之间的区别。
　　图1-3编写单元测试的传统方法。虚线表示人们认为是可选的行为
　　图1-4测试驱动开发概要图。注意，这是一个螺旋式的过程：编写测试，编码，
　　重构，编写下一个测试。这张图展示了TDD的增量特性：小步骤的积累得
　　到高质量的最终结果
　　如图1-4所示，TDD和传统开发方式不同。你首先编写一个会失败的测试，然后创建产品代码，并确保这个测试通过，接下来是重构代码或者创建另一个会失败的测试。
　　本书关注的是编写优秀单元测试的技术，而非测试驱动开发方法，但是我非常推崇TDD。我曾经用TDD编写过几个重要的应用程序和框架，也管理过使用TDD的团队，还讲授过100多堂关于TDD和单元测试技术的课程和讲习班。在我的整个职业生涯中，我发现TDD能帮助创建高质量代码和高质量的测试，还能更好地设计代码。我相信TDD对你也会有帮助，但是你需要付出很多（学习的时间、实施的时间，以及更多），当然这些付出绝对是值得的。
　　我们必须认识到，TDD并不能保证项目一定成功，或者测试都健壮、可维护。人们很容易陷入TDD技术的细节，而忘记关注编写单元测试的方式：测试的命名，测试的可维护性和可读性，以及是否测试了正确的内容，或者测试本身是否有缺陷。这也是我要写这本书的原因。
　　TDD的技术相当简单。
　　(1) 编写一个会失败的测试，以证明产品中代码或者功能的缺失。编写测试的时候，要假设产品代码已经能工作 了，这样测试的失败就说明产品代码中有缺陷。如果要在一个计算器类中添加一个新功能，记住LastSum的值，我就会写一个测试来验证LastSum确实是正确的值。这个测试最初会编译失败，只有在添加了需要的代码后，编译才能通过（但是还没有实现记住数值的真正功能），然后测试可以运行，但是会失败，因为我还没有实现所需的功能。
　　(2) 编写符合测试预期的产品代码，使测试通过。产品代码应该尽量简单。
　　(3) 重构代码。如果测试通过了，你就可以编写下一个单元测试，或者进行重构，使代码可读性更强，或者去除重复代码等。
　　重构可以在编写多个测试之后进行，也可以在每个测试后都进行。重构是一项重要的实践，它确保代码更易读，更好维护，同时还依然能通过之前编写的所有测试。
　　定义重构意味着在不改变一段代码功能的前提下修改代码。如果重命名了一个
　　方法，你就进行了重构。如果把一个较大的方法分成了多个较小的方法调用，你也对代码进行了重构。代码还是具有同样的功能，但重构后变得更容易维护、理解、调试和修改。
　　这些步骤听起来很技术性，但是其间蕴藏着很多的智慧。如果实施得当，TDD可以极大地提高代码质量，减少缺陷数量，提升你对代码的信心，缩短发现缺陷的时间，优化代码设计，让你的经理更满意。但如果实施不当，TDD可能导致项目延期，浪费时间，打击士气，降低代码质量。TDD是一把双刃剑，很多人在失败之后才体会到这一点。
　　确切地说，没有人会告诉你TDD有一个最大的优点：如果一个测试失败了，没有经过修改再次运行又成功了，你其实是在测试这个测试本身。如果你预期一个测试会失败，但它却成功了，那测试本身可能有缺陷，或者测试的对象不对。如果一个测试之前失败了，你现在预期它成功，它却依然失败，那测试可能有缺陷，或者测试预期的结果不正确。
　　本书讨论的是可读、可维护并且可靠的测试，但是只有当你看到测试该成功的时候成功，该失败的时候失败，才能获得对它们最大的确定。在这方面，TDD对你会有很大帮助，这也是为什么和编码之后进行单元测试相比，开发人员在使用TDD开发时进行代码调试要少得多。如果开发者信任测试，他们不会为了只是以防万一而调试代码。这种信任只能通过看到测试的两方面获得：该失败的时候失败，该成功的时候成功。
　　1.7成功进行TDD的三种核心技能
　　成功进行测试驱动开发，你需要三种技能集：知道如何编写优秀的测试、在编码前编写测试，以及良好的测试设计。
　　仅仅做到先编写测试，并不能保证测试是可维护、可读以及可靠的。你正在读的这本书讲的全都是进行优秀单元测试的技巧。
　　仅仅做到编写的测试可读、可维护，并不能保证你获得先编写测试的各种好处。市面上大部分讲TDD的书介绍的都是测试优先的技能，而不讲授优秀测试技能。我特别推荐Kent Beck的Test-Driven Development: by Example（Addison-Wesly Professional，2002）。
　　仅仅做到先编写测试，并且测试可读、可维护，并不能保证你得到一个设计完善的系统。设计能力才是使代码优美、可维护的关键。关于这方面的好书，我推荐Steve Freeman和Nat Pryce的Growing Object-Oriented Software, Guided by Tests（Addison-Wesly Professional，2009）以及Robert C. Martin的《程序员的职业素养》。
　　学习TDD的一个实用方法是分别学习以上三个方面的技能。也就是说，一次只关注一种技能，忽略其他的技能。我经常看到人们试图同时学习这三种技能，学习过程非常艰难，最后因为难度太大而放弃。所以我推荐一次只关注一种技能的学习方法。
　　通过采用这种比较循序渐进的方法来学习这个领域的知识，你一段时间只关注一个方面，不会总是担心在别的领域犯错。
　　至于按什么顺序学习，我没有什么具体的设想。我很希望了解你学习这些技能的经验和学习时的建议。你可以在http://osherove.com获取我的联系方式。
　　1.8小结
　　在本章中，我定义了一个优秀单元测试应具有的特质，如下所示：
　　一段自动化的代码，它调用另一个方法，然后检验关于此方法或类的逻辑行为的某些假设；
　　用一个自动化测试框架编写。
　　容易编写。
　　运行快速。
　　能由开发团队里的任何人重复执行。
　　要理解什么是一个单元，你需要弄清楚自己以前所做的是什么类型的测试。你发现以前所做的是集成测试，因为它测试的是一组互相依赖的单元。
　　掌握区分单元测试和集成测试的知识很重要。作为一个开发人员，你每天都会用到这一知识，以决定在何处测试、何时编写何种类型的测试，以及对一个具体的问题用哪种测试更好。这一知识也能帮助修复那些已经令你头疼不已的测试。
　　我们还了解了不使用框架进行集成测试的缺点：这种测试很难编写及自动化，运行缓慢，需要进行配置。虽然在项目中的确需要集成测试，但单元测试能够在开发过程的早期提供更多的价值，在这个阶段缺陷较小，更容易发现，需要检查的代码也比较少。
　　最后，我们探讨了测试驱动开发，包括它与传统编码方式有什么不同之处，以及它有哪些基本好处。TDD能帮助你确保测试代码的代码覆盖率（你的测试调用了多少产品代码）非常高（逻辑代码覆盖率接近100%），确认测试可信。它让你看到测试在预期的时候成功或者失败，以此来“测试你的测试”。TDD还有其他的许多好处，例如辅助代码设计，降低代码复杂度，帮助你逐步解决难缠的问题。但是如果你不知道怎么编写优秀的测试，就不可能持续地成功实践TDD。
　　在下一章里，你将学习使用.NET开发者最常用的单元测试框架NUnit，开始编写你的第一个单元测试。