图书信息书名： 测试驱动开发的艺术
书号： 978-7-115-23836-8
原书名： Test Driven: Practical TDD and Acceptance TDD for Java Developers
原出版社： Manning Publications
丛书名： 图灵原版计算机科学系列
分类： 计算机 >> 软件工程 >> 开发过程系列
作者： Lasse Koskela
译者： 李贝
出版日期： 2010-11-01
语种： 简体中文
开本： 16开
页数： 348
简介本书介绍了一种更快更好的软件开发方法——测试驱动开发。全书共分三部分：第一部分讲述了TDD和ATDD的相关知识、基本概念、方法，为测试驱动开发打下基础；第二部分将测试驱动开发用于具体的实践，重点讲解了TDD的各种技术；第三部分着重介绍了验收测试驱动开发，包括Fit框架、实现验收测试的方法等，最后讲解了引入TDD的各种技巧。
本书浓缩了作者多年的开发经验，适合各类Java开发人员学习参考。
目录第一部分 TDD入门
第1章 综述 2
1.1 挑战：用正确的方法解决正确的问题 3
1.1.1 糟糕的代码质量 3
1.1.2 不能满足客户需求 4
1.2 解决方案：测试驱动 4
1.2.1 高质量的TDD 5
1.2.2 用ATDD满足客户需求 6
1.2.3 这对我有什么好处 7
1.3 正确地做事：TDD 9
1.3.1 测试—编码—重构 9
1.3.2 增量式开发 12
1.3.3 重构以保持代码的健康 16
1.3.4 保证软件正常运行 18
1.4 做正确的事：ATDD 20
1.4.1 名字的含义 20
1.4.2 紧密协作 21
1.4.3 把测试作为沟通的共同语言 22
1.5 TDD工具 23
1.5.1 使用xUnit做单元测试 23
1.5.2 支持ATDD的测试框架 23
1.5.3 持续集成及构建 24
1.5.4 代码覆盖率 25
1.6 小结 26
第2章 TDD入门 28
2.1 从需求到测试 29
2.1.1 分解需求 29
2.1.2 什么是好的测试 30
2.1.3 依照测试的列表工作 30
2.1.4 意图编程 30
2.2 选择第一个测试 31
2.2.1 创建测试列表 31
2.2.2 写第一个失败的测试 32
2.2.3 通过第一个测试 34
2.2.4 再加一个测试 36
2.3 广度优先，深度优先 38
2.3.1 继续使用伪实现 39
2.3.2 清除掉伪实现 39
2.4 别忘了重构 41
2.4.1 测试代码中的可重构之处 42
2.4.2 移除多余的测试 43
2.5 添加错误处理 44
2.5.1 验证异常 44
2.5.2 把方法重构得更短些 45
2.5.3 保持方法平衡 46
2.5.4 验证异常中的详细信息 47
2.6 无穷尽的测试 48
2.6.1 性能测试 48
2.6.2 有些失望的结局 49
2.7 小结 50
第3章 小步重构 51
3.1 探寻解决方案 51
3.1.1 用Spike开发原型 52
3.1.2 写测试学知识 52
3.1.3 学习API的Spike样例 52
3.2 以受控的方式修改设计 54
3.3 进一步延伸新设计 61
3.3.1 保持兼容 62
3.3.2 替换实现 66
3.4 小结 68
第4章 TDD的概念与模式 69
4.1 如何编写及通过测试 70
4.1.1 测试选择技巧 70
4.1.2 实现技巧 72
4.1.3 测试驱动的基本准则 73
4.2 重要的测试概念 74
4.2.1 夹具是测试的上下文 74
4.2.2 用测试替身替换依赖 76
4.2.3 基于状态及基于交互的的测试 76
4.3 近处观察测试替身 78
4.3.1 测试替身的例子 78
4.3.2 伪实现、测试桩和模拟对象 79
4.3.3 模拟对象实战 80
4.4 提高设计的可测试性的准则 81
4.4.1 尽量使用组合而非继承 82
4.4.2 避免使用static关键字以及Singleton模式 83
4.4.3 隔离依赖 84
4.4.4 注入依赖 86
4.5 单元测试模式 88
4.5.1 断言模式 89
4.5.2 夹具模式 92
4.5.3 测试模式 95
4.6 在遗留代码基础上工作 101
4.6.1 测试驱动遗留开发 101
4.6.2 分析变化 102
4.6.3 准备好变化 103
4.6.4 测试驱动变更 103
4.7 小结 104
第二部分 针对特定技术应用TDD
第5章 测试驱动Web组件 106
5.1 在60秒内介绍Web应用中的MVC 107
5.2 控制器 107
5.2.1 测试驱动Java Servlets 108
5.2.2 测试驱动Spring控制器 117
5.3 用测试先行的方法构建视图 120
5.3.1 用JspTest测试驱动JSP 121
5.3.2 测试驱动Velocity模板 125
5.4 在基于控件的Web框架基础上TDD 129
5.4.1 剖析典型框架 130
5.4.2 用测试先行的方法开发Wicket页面 130
5.5 小结 135
第6章 测试驱动数据访问 137
6.1 探索问题领域 137
6.1.1 跨越边界的数据访问 138
6.1.2 用DAO模式分层 138
6.2 用单元测试驱动数据访问 139
6.2.1 JDBC API的缺点 140
6.2.2 用Spring的JdbcTemplate简化开发 144
6.2.3 用Hibernate轻松地做TDD 149
6.3 编码前写集成测试 155
6.3.1 什么是集成测试 155
6.3.2 选择数据库 157
6.4 集成测试实战 159
6.4.1 第一个Hibernate集成测试 159
6.4.2 创建数据库模式 162
6.4.3 实现产品代码 164
6.4.4 用事务夹具保持数据清洁 165
6.5 为集成测试填充数据 166
6.5.1 用Hibernate填充对象 167
6.5.2 用DbUnit填充数据 168
6.6 使用单元测试还是集成测试 172
6.6.1 在TDD周期中使用集成测试 172
6.6.2 两全其美 173
6.7 文件系统访问 173
6.7.1 项目中实际遇到的一个问题 174
6.7.2 提高文件访问可测试性的实践 174
6.8 小结 175
第7章 测试驱动不可预测功能 177
7.1 测试驱动时间相关功能 177
7.1.1 例子：日志和时间戳 177
7.1.2 抽象出系统时间 179
7.1.3 用虚设的系统时间测试日志输出 181
7.2 测试驱动多线程代码 184
7.2.1 该测什么 184
7.2.2 线程安全 185
7.2.3 阻塞操作 189
7.2.4 启动及中止线程 191
7.2.5 异步执行 193
7.2.6 线程同步 195
7.3 标准同步对象 196
7.3.1 信号量 196
7.3.2 latche 196
7.3.3 barrier 196
7.3.4 futures 197
7.4 小结 197
第8章 测试驱动Swing代码 198
8.1 Swing UI中该测试什么 198
8.1.1 内部基础设施及实用程序 199
8.1.2 渲染及布局 199
8.1.3 交互 199
8.2 可测试UI代码的模式 200
8.2.1 经典MVP 201
8.2.2 Supervising Controller 201
8.2.3 Passive View 203
8.3 测试视图控件的工具 205
8.3.1 为什么要用工具 205
8.3.2 TDD友好的工具 206
8.4 测试驱动视图组件 210
8.4.1 着手设计 211
8.4.2 添加及操作标准控件 212
8.4.3 绘图 216
8.4.4 给点添加行为 224
8.5 小结 227
第三部分 基于ATDD构建产品
第9章 解析验收测试驱动开发 230
9.1 用户故事介绍 231
9.1.1 故事的格式 231
9.1.2 讲故事的力量 231
9.1.3 用户故事的例子 232
9.2 验收测试 232
9.2.1 故事的样例测试 232
9.2.2 验收测试的特征 233
9.2.3 实现验收测试 236
9.3 理解过程 237
9.3.1 ATDD周期 237
9.3.2 迭代内的ATDD 242
9.4 作为团队活动的ATDD 245
9.4.1 客户角色定义 245
9.4.2 客户与谁一起写测试 246
9.4.3 需要多少测试人员 247
9.5 ATDD的好处 247
9.5.1 “完成”的定义 247
9.5.2 协作 248
9.5.3 信任及承诺 249
9.5.4 通过例子验收 249
9.5.5 弥合差距 249
9.6 我们究竟要测试什么 250
9.6.1 应该针对UI测试吗 250
9.6.2 可以使用部分系统的伪实现吗 251
9.6.3 应该直接测试领域逻辑吗 251
9.7 工具概览 252
9.7.1 基于表格的框架 252
9.7.2 基于文本的框架 253
9.7.3 基于脚本语言的框架 254
9.7.4 自制工具 254
9.8 小结 254
第10章 用Fit创建验收测试 256
10.1 Fit是什么 256
10.1.1 用Fit进行ATDD 257
10.1.2 包含夹具表的测试文档 259
10.1.3 夹具：表格和类的结合 260
10.2 三个内建夹具 261
10.2.1 ColumnFixture 261
10.2.2 RowFixture 263
10.2.3 ActionFixture 266
10.2.4 扩展内建夹具 268
10.3 FitLibrary对内建夹具的扩展 269
10.3.1 DoFixture 269
10.3.2 SetUpFixture 272
10.3.3 还有更多功能 273
10.4 执行Fit测试 273
10.4.1 单个测试文档 274
10.4.2 把所有测试放在一个目录结构中 274
10.4.3 把测试整合进自动化测试中 275
10.5 小结 276
第11章 执行验收测试的策略 277
11.1 验收测试该检测什么 277
11.1.1 抓住问题本质 278
11.1.2 避免波动频繁界面 278
11.1.3 在技术障碍最小的地方越过 279
11.2 实现方式 279
11.2.1 端到端 280
11.2.2 绕过UI进行测试 281
11.2.3 直接测试内部逻辑 284
11.2.4 替换无关组件 285
11.2.5 测试后门 286
11.3 技术相关考虑 287
11.3.1 库 287
11.3.2 无界面的分布式系统 288
11.3.3 控制台应用 289
11.3.4 GUI应用 290
11.3.5 Web应用 293
11.4 常见问题的处理技巧 295
11.4.1 加快测试执行速度 296
11.4.2 减少测试的复杂度 299
11.4.3 管理测试数据 300
11.5 小结 301
第12章 TDD应用 302
12.1 成功采用TDD的必要条件 302
12.1.1 理解本质 302
12.1.2 紧迫感 303
12.1.3 成就感 303
12.1.4 表现诚实 304
12.1.5 变革的时机 304
12.2 让其他人参与进来 305
12.2.1 引导变革的角色和能力 305
12.2.2 改变需要时间 307
12.3 如何应对阻力 307
12.3.1 识别阻力 307
12.3.2 应对阻力的三种常见方法 309
12.3.3 应对阻力的技巧 310
12.3.4 挑选战场 312
12.4 如何推进变革 313
12.4.1 造势 313
12.4.2 降低门槛 314
12.4.3 培训 315
12.4.4 共享及感染 316
12.4.5 指导和督促 317
12.4.6 通过分配角色让人们参与进来 318
12.4.7 打破稳定状态 319
12.4.8 迟后的奖励 319
12.5 小结 319
附录A JUnit 4简明教程 321
附录B JUnit 3.8简明教程 323
附录C EasyMock简明教程 325
附录D 通过Ant运行测试 327
相关资源 331
前言七年前，正值全球IT产业繁荣时期，大大小小的软件公司都发了疯似地想赶上下一波IPO，招聘市场火爆异常。我也在此时投身到繁荣的新媒体产业，开始了我的编程生涯。从此我没日没夜地鼓捣各种代码段，配置服务器，往生产系统里上传PHP脚本，似乎一切尽在掌握。
一个九月的雨夜，又是加班到很晚，突然间我的心脏似乎停止了跳动：哎呀！我刚才做了什么？我是否删掉了生产数据库里的所有数据？好像是的！看来我只有卷铺盖走人了。我怎么才能把数据找回来呢？刚才还以为只是测试用的数据库呢！这种悲剧怎么能发生在我头上？然而，确实发生了。
第二天我没有被炒鱿鱼，主要原因是，看来客户对我删掉的数据并不太在意。而且，看来别的人也都干过类似的蠢事——他们安慰我说：大家都可能犯错。我得到一个教训，那个该死的夜晚也标志着我开始追求一种负责任的、可靠的软件开发态度。
几年以后，我换了家国际性咨询公司工作，为其他大公司开发应用和后台系统。在短短几年的职业生涯里我学到了不少东西，这得归功于我以前趴在电脑前熬夜的努力，而新工作无疑是我磨炼实战技艺的好机会。我又一次认为我已经对于软件开发行当熟门熟路了。可是我又错了，显然我比自己想象的要知道得少。我几乎每天都能学到重要的新知识。
我最重大的发现改变了我对软件开发的认识，极限编程（XP）给了我全新的视角，让我知道什么才是正确的软件开发方法。在我看来，XP把我过去行之有效的披荆斩棘式的编程方式与一种系统的、训练有素的工作方法结合在一起。XP项目除了能让开发团队更接近客户之外，最打动我的就是测试驱动开发（TDD）了。我以前认为编程和单元测试是两个分离的活动，现在“编码之前先写测试”这样一个简单的理念完全颠覆了我的旧思想。
TDD绝非闲庭信步那样轻松。我时刻提醒自己要先写测试，一开始能做到，可是只过了半个小时，我就忘了遵守，还没有测试就在修改代码。随着时光流逝，我越来越能够坚持测试先行的编程方法，甚至一整天都不会落入往日的陋习中。接着我会被一段代码难住，凭我的能力我无法征服它。再往后，我能理解应该怎么做，但我的手法还不够用。再后来，我不知道如何能四两拔千斤地巧妙解题，却又往往不愿意愚公移山般地用笨办法尝试。年复一年，我学会了越来越多的技巧，掌握了越来越多的工具，终于获得了现在的功力。
我写此书的目的是让诸君不必像我以前那样笨拙地克服种种困难，你们有此书在手可以轻松地前行。对我而言，学会了测试先行，深刻地影响了我工作的方法和对编程的认识，正如敏捷方法改变了我对软件开发的认识。我希望你们也能学会测试先行。
