具体描述
所有程序员都知道应该做单元测试，但为什么你们没有做呢？是因为对单元测试不够了解，还是嫌单元测试麻烦，抑或认为单元测试的投入产出比太低？不管因为什么，你都应该看看这本书。
本书在第1版基础上新增了很多内容，不过仍然会手把手地教你从第一个单元测试开始写起，通过简单的例子让你理解如何编写好维护、易明白和可靠的单元测试。在此基础上，本书自然过渡到一些较为高级的主题，比如模拟对象、存根和隔离框架（Moq、FakeItEasy和Typemock Isolator等），同时涉及测试模式，以及组织、重构代码的技巧，乃至怎么测试“不可测试”的代码。另外，其中还介绍了集成测试和关联数据库的测试技术。
本书代码示例虽然是用C#写的，但有关单元测试的技术和思想适合所有使用静态类型语言（如VB.NET、Java、C++）的测试人员，以及测试驱动开发人员学习借鉴。
主要内容：
创建可读、可维护和可靠的测试
伪对象、存根、模拟对象和隔离（模拟）框架
简单的依赖注入技术
重构遗留代码
第2版新增：
受限与不受限的隔离框架及其工作原理
隔离框架的特征及Typemock等框架的内部工作机制
更多实施单元测试的可用技术
调优示例代码的设计（避免使用属性设置方法，转而使用构造函数注入）
点到为止，探讨SOLID原则
构建自动化及测试模式
对设计与可测试性的新认识
更新工具与框架（附录A）
作者简介
作者简介:
Roy Osherove
世界著名单元测试专家，常年为世界各地的开发团队提供咨询和培训服务，并在各种大会上发表演讲，内容包括单元测试及测试驱动开发的艺术、团队领导力和敏捷开发实践。其个人技术博客osherove.com平均月独立访问量约50 000，提供了各种技术视频及其他培训信息，另著有Notes to a Software Team Leader: Growing Self Organizing Teams。
译者简介：
金迎
1997年毕业于北京大学计算机系，从事软件开发工作数年；2004年毕业于中科院计算所计算机应用技术专业，之后进入软件测试行业，具有丰富的手工和自动化测试的项目经验。
目录信息
第1章 单元测试基础 2
1.1 逐步定义单元测试 2
1.1.1 编写优秀单元测试的重要性 4
1.1.2 我们都写过（某种）单元测试 4
1.2 优秀单元测试的特性 5
1.3 集成测试 5
1.4 什么是优秀的单元测试 9
1.5 一个简单的单元测试范例 9
1.6 测试驱动开发 12
1.7 成功进行TDD的三种核心技能 15
1.8 小结 15
第2章 第一个单元测试 17
2.1 单元测试框架 18
2.1.1 单元测试框架提供什么 18
2.1.2 xUnit框架 20
2.2 LogAn项目介绍 20
2.3 NUnit初步 20
2.3.1 安装NUnit 21
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
· · · · · · (收起)
读后感
读不下去了。。。文字和配图根本驴头不对马嘴。。。代码也是乱乱的。。。 return后边突然就来了一个Return.... 文字写的是FakeService，图里是MockWebService... 哎，看着好蛋疼。。。
评分这本书由浅入深的介绍了单元测试方方面面的知识，包括最基本的单元测试的定义、如何编写简单的单元测试、如何解除系统中的依赖(在单元测试中)之外，还告诉我们如何编写优秀的单元测试，以及如何向组织中引入单元测试，如何处理遗留代码的问题，如何设计易于测试的代码。全书的...
评分读不下去了。。。文字和配图根本驴头不对马嘴。。。代码也是乱乱的。。。 return后边突然就来了一个Return.... 文字写的是FakeService，图里是MockWebService... 哎，看着好蛋疼。。。
评分读不下去了。。。文字和配图根本驴头不对马嘴。。。代码也是乱乱的。。。 return后边突然就来了一个Return.... 文字写的是FakeService，图里是MockWebService... 哎，看着好蛋疼。。。
评分读不下去了。。。文字和配图根本驴头不对马嘴。。。代码也是乱乱的。。。 return后边突然就来了一个Return.... 文字写的是FakeService，图里是MockWebService... 哎，看着好蛋疼。。。
用户评价
这本书最让我感到震撼的是它对测试复杂度的管理哲学。我们都知道，随着系统规模的扩大，测试的维护成本往往会呈指数级增长，这使得很多团队最终放弃了严格的测试流程。这本书提供了一种清晰的框架来理解和平衡这种复杂度：何时应该使用模拟（Mocking），何时应该使用桩（Stubbing），以及如何设计出真正具有“独立性”的测试用例。作者对依赖注入（Dependency Injection）在测试中的应用进行了非常深入的探讨，清晰地界定了“好的依赖注入”与“过度工程化”之间的微妙界限。它鼓励开发者将测试视为代码的积极组成部分，而不是一个事后补救的步骤。读完后，我对如何组织我的测试套件有了全新的认识，不再是简单地把测试文件堆在一起，而是开始构建一个结构清晰、易于导航和快速反馈的质量反馈循环系统。
评分对于那些刚踏入软件开发行业的新手来说，我强烈推荐这本书作为你们的启蒙读物，但前提是，你们必须带着批判性的眼光去吸收。这本书的价值不在于教你如何配置JUnit或NUnit，而是让你明白，为什么你需要它们，以及在什么情况下它们可能适得其反。书中的一部分章节专门讨论了如何处理那些遗留的、缺乏良好设计的代码库进行测试的策略，这正是大量经验丰富的工程师日常会遇到的痛点。作者没有回避现实的残酷性，而是提供了一套渐进式的、务实的改进方案，比如如何引入“隔离层”来逐步驯服那些难以控制的依赖项。这种兼具理论高度和实战深度的内容，使得这本书的含金量非常高。它不只是理论宣讲，更像是一场资深架构师坐在你旁边，手把手教你如何“打扫房间”的私教课。
评分我最近几年一直在跟进各种新的开发范式和工具集，但说实话，很多新东西来得快去得也快，让人疲于奔命。直到我翻开这本关于测试艺术的著作，才发现真正有价值的知识是跨越时间周期的。这本书的叙事方式非常引人入胜，它不像传统教科书那样枯燥乏味，而是充满了作者多年实践中总结出的智慧和教训。它没有直接给我一个现成的答案，而是提供了一套强大的思维工具箱，让我能够独立面对未来出现的任何新的技术挑战。比如，书中对“测试的覆盖率陷阱”的分析，让我意识到盲目追求高百分比数字是多么的危险和误导。作者通过生动的案例展示了如何识别那些关键业务逻辑，并确保这些部分拥有真正有意义的、能够捕获错误的测试，而不是那些仅仅在表面上跑通的代码路径。这是一种对“有效性”的极致追求，而非对“数量”的盲目崇拜。
评分我发现这本书的语言风格非常精准和克制，没有过多的煽情或夸大的宣传，完全是用技术事实和逻辑严密的论证来构建其观点。其中关于测试金字塔的讨论，已经超越了教科书上的基础定义，进入了对现实世界中各种架构限制的深刻反思。它并没有武断地规定“必须”是什么样的比例，而是探讨了在不同的业务场景下，如何动态地调整资源分配，以达到最高的风险覆盖率。尤其是对集成测试和端到端测试的边界划分，作者给出了许多非常实用的参考模型，这帮助我成功地在团队内部说服了那些倾向于编写过多缓慢、脆弱的E2E测试的同事。这本书的影响是深远的，它不仅仅是关于如何写测试代码，更是关于如何构建一种对质量负责任的工程文化。
评分这本书简直是软件工程领域的里程碑！它没有过多纠缠于那些花里胡哨的、转瞬即逝的技术框架，而是深入骨髓地探讨了软件测试的哲学和核心思想。我尤其欣赏作者在描述“为什么”要做单元测试时所展现出的洞察力，而不是简单地堆砌“如何”使用某个工具。书中对于“可测试性设计”的讲解，简直是醍醐灌顶，让我开始重新审视自己过去编写代码的习惯。以前总觉得测试是写完代码后的一个负担，但读完这部分内容后，我明白了，良好的测试性其实是高质量代码的内在属性。它引导我们去构建那些易于隔离、职责清晰的模块，这不仅让测试变得简单，更让代码本身的结构更加健壮。那种对底层原理的剖析，那种将测试提升到设计层面去考量的深度，是其他许多市面上流行的“快速入门”书籍完全无法比拟的。这本书更像是一本内功心法，而非招式手册，它教会你如何建立一套可持续、可信赖的质量保障体系。
评分虽然薄，但颇多干货
评分阅读了前两章，对单元测试的定义值得一看
评分写的比较细致，先粗略翻阅了一下，后面在好好研读。
评分保持代码可测性，不能依赖测试来证明程序正确性
评分作者个人风格很明显，提到了很多具体工具，适合C#或Java，不适于Python。似乎不适合作为入门书
相关图书
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2026 book.wenda123.org All Rights Reserved. 图书目录大全 版权所有