测试驱动开发的艺术
当前位置:首页 > 计算机网络 > 软件工程/开发项目管理 > 测试驱动开发的艺术
出版社:人民邮电出版社
出版日期:20101023
ISBN:9787115238368
作者:Lasse Koskela
页数:348页
作者简介
在传统的软件开发中，开发人员对于代码是否正确心中无底，一切依赖于后期的测试环节。极限编程反其道而行之，主张采用测试驱动开发（TDD）的方法，即通过测试定义所要开发的功能的接口，然后实现功能的开发过程。TDD通过不断地测试推动代码的开发，既简化了代码，又保证了软件质量。
本书采用“手把手”的教学方式，通过大量实例来解释TDD，还专门用几章的篇幅来讲解如何为难于测试的技术编写单元测试。全书内容循序渐进，先侧重基础内容，讨论测试驱动开发和验收，然后进入动手实践部分，逐一讲解如何对各种技术应用TDD，最后介绍基于验收测试驱动的测试先行的方式构建完整的系统。
本书面向各个层次的Java程序员。面对变化的世界，请张开双臂，拥抱极限编程，拥抱TDD。
书籍目录
第一部分 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产业繁荣时期，大大小小的软件公司都发了疯似地想赶上下一波IP0，招聘市场火爆异常。我也在此时投身到繁荣的新媒体产业，开始了我的编程生涯。从此我没日没夜地鼓捣各种代码段，配置服务器，往生产系统里上传PHP脚本，似乎一切尽在掌握。一个九月的雨夜，又是加班到很晚，突然间我的心脏似乎停止了跳动：哎呀！我刚才做了什么？我是否删掉了生产数据库里的所有数据？好像是的！看来我只有卷铺盖走人了。我怎么才能把数据找回来呢？刚才还以为只是测试用的数据库呢！这种悲剧怎么能发生在我头上？然而，确实发生了。第二天我没有被炒鱿鱼，主要原因是，看来客户对我删掉的数据并不太在意。而且，看来别的人也都干过类似的蠢事——他们安慰我说：大家都可能犯错。我得到一个教训，那个该死的夜晚也标志着我开始追求一种负责任的、可靠的软件开发态度。几年以后，我换了家国际性咨询公司工作，为其他大公司开发应用和后台系统。在短短几年的职业生涯里我学到了不少东西，这得归功于我以前趴在电脑前熬夜的努力，而新工作无疑是我磨炼实战技艺的好机会。我又一次认为我已经对于软件开发行当熟门熟路了。可是我又错了，显然我比自己想象的要知道得少。我几乎每天都能学到重要的新知识。我最重大的发现改变了我对软件开发的认识，极限编程（XP）给了我全新的视角，让我知道什么才是正确的软件开发方法。在我看来，XP把我过去行之有效的披荆斩棘式的编程方式与一种系统的、训练有素的工作方法结合在一起。XP项目除了能让开发团队更接近客户之外，最打动我的就是测试驱动开发（TDD）了。我以前认为编程和单元测试是两个分离的活动，现在“编码之前先写测试”这样一个简单的理念完全颠覆了我的旧思想。TDD绝非闲庭信步那样轻松。我时刻提醒自己要先写测试，一开始能做到，可是只过了半个小时，我就忘了遵守，还没有测试就在修改代码。随着时光流逝，我越来越能够坚持测试先行的编程方法，甚至一整天都不会落入往日的陋习中。接着我会被一段代码难住，凭我的能力我无法征服它。再往后，我能理解应该怎么做，但我的手法还不够用。再后来，我不知道如何能四两拔千斤地巧妙解题，却又往往不愿意愚公移山般地用笨办法尝试。年复一年，我学会了越来越多的技巧，掌握了越来越多的工具，终于获得了现在的功力。我写此书的目的是让诸君不必像我以前那样笨拙地克服种种困难，你们有此书在手可以轻松地前行。对我而言，学会了测试先行，深刻地影响了我工作的方法和对编程的认识，正如敏捷方法改变了我对软件开发的认识。我希望你们也能学会测试先行。
内容概要
Lasse Koskela 程序员，软件开发培训师、咨询师，任职于芬兰知名软件公司Reaktor，致力于为客户提供软件性能提升解决方案；同时也是开源软件的忠实拥护者。其博客地址为：http://lassekoskela.com/thoughts/。
媒体关注与评论
“在TDD领域，这本书是当之无愧的No.1，内容简单易懂。文笔简炼精要。” ——Ionel Condor，Cluj-Napoca公司“这本书设置的门槛并不低，但通读后，你绝对可以轻松达到要求的高度并跨越它。作者旨在传播TDD哲理。阐述TDD的实际应用。促进TDD在其他领域的应用。让更多的人分享其来之不易的经验教训。” ——JavaLobby.org“作者见解独到，行文幽默犀利，佩服至极！” ——Michael Feathers，Object Mentor公司咨询专家“书中的这些宝贵经验如果要我自己去摸索，估计得花上几年时间。” ——Laurent Bossavit，2006年Gordon Pask奖得主
章节摘录
插图：·提供一个完整的业务对象，此对象所有的必填属性也是完整的业务对象；·在整个生命周期内都可以返回被请求的对象；·可以定制所返回的对象；·测试过程中可以更新对象；·如果有必要，可以在测试结束时回收对象及所有关联对象。总的来说，对象母亲模式是一个复杂的对象工厂，用于创建领域对象（domain object）的整个对象网络（object graph），还可以创建出不同状态下的实例。此外，对象母亲也可以提供方法修改某个领域对象，例如在对象间建立关联关系、移除关联关系、或者把对象设置为特征状态。除了可以消除测试代码中的重复，对象母亲模式还可以使TDD的初学者方便的获得需要的对象，这可以鼓励他们多写测试。若创建对象过于麻烦，他们也许会打消写测试的念头。不少团队在开发过程中都会定义一套人物角色（personas），若把对象母亲与这套角色结合使用，效果会更好。例如，若团队定义了爱丽丝、贝利和克拉克等人物角色，每个人都代表交易系统中的不同角色，这时对象母亲应该把这些人物作为其API接口。这种概念上的关联可以帮我们更容易的编写测试，不用翻查API，更不用深入创建方法内部弄清楚该使用哪个对象做测试。我们只需要说：“好，我需要一个购买订单，这订单由克拉克提交，吉姆审批。”虽然对象母亲是个强有力的工具，能够有效的促进测试的编写，不过构建出整套对象母亲需要不少时间。所以，我建议小步重构当前的测试代码，起先可以引入紧凑的创建方法，最后把这止匕创建方法及其提供的测试数据整个移到对象母亲中。
图书封面
发布书评
精彩书评 (总计6条)
-
本文同时发在我的博客上：http://www.cnblogs.com/yuyijq/archive/2010/12/08/1900789.html在北京的天气正在一天比一天冷的11月底我收到了这么一本标题带有艺术的书籍。我本来对技术书籍标上艺术或之道或之美的标题很厌恶。而最近各个出版商却对这样的标题很热衷，不过厌恶归厌恶，这本书还是给我带来了一丝丝温暖。目录翻开目录我就发现，中文出版社将这本书标题定为艺术实在是掩盖了这本书散发出浓浓的“实践”的气息。没看到任何的艺术，只看到满眼的具体实践，而且与日常工作联系十分的紧密。第一章第一章作者用不大的篇幅介绍了一下TDD的概念，这部分并没有任何出彩的部分，大部分以TDD为名的书籍都有这样的介绍，不过本书不同的是介绍了ATDD（验收测试驱动开发），这在大部分TDD的书里是没有的。敏捷软件开发中度量进度的标准就是实际交付物，并不是你用单元测试驱动出来了多少代码。那么如果我们用验收测试驱动出来代码，然后让验收测试变绿，这算不算呼应敏捷软件开发的进度度量呢？所以很多TDD的书对ATDD的忽视也算一种缺憾。第二、三章不管你看了多少TDD的书，如果没有看到真实的示例，你还是觉得这些都是浮云。没有代码就开始测试？我测什么，怎么测？作者用了两章的篇幅用TDD的方式来编写了一个功能很弱但也算完备的模板引擎。并在字里行间不断的提醒我们：测试->实现->重构的步骤，一次又一次的警告我们不要贪多，重构要小步进行。从这点，让我回忆起有多少次Rollback一整天的工作，仅仅就是因为违背了这些看似简单的规则。第三章对我的触动更为深刻，在公司里每当我们无法对一个用户故事划分出清晰任务（完成这个故事采用的先后步骤），我们就先要进行Spike，然后我们就可以划分出任务了，从而也可以估计出比较合理的点数。不过作者所阐述的依照测试列表工作而不要根据任务列表倒是没有尝试过，有机会可以尝试一下。在2.6节作者写了个简单的性能测试，不过却在我心中起了不小的波动。性能这东西是个非常难以捉摸的怪物，考虑早了可能根本抓不着瓶颈到底在哪儿，考虑迟了可能为时已晚。如果我们跟用户谈好可接受的性能，然后我们编写一个性能测试，这个测试就像一个警报一样，只要性能一突破这个防线，警报就拉响，我们就要查查是我们刚刚编写的哪段代码影响了我们的性能。嗯，这也许是个很可行的方法。在阅读第二、三章的时候，如果你能打开你最顺手的IDE，和作者一道使用TDD驱动出这个模板引擎，我相信你将收获颇多。不过你可能要嚷道，我们的项目可比这复杂得多，我们的项目需要几十人月，有多少多少代码。嗯，我知道你们的项目很复杂，但是复杂的项目也是非常多简单的代码有机的组合而成。在你实现一个功能的时候你不要想着你的项目有多复杂，你只需要关注你当前的测试就可以了。这也是作者在这两章里时常提醒的原则。第四章怎么样，跟着作者使用TDD的方式完成了这么个小“模板引擎”，是不是觉得单元测试很简单？如果你这么想那就上钩了，要写单元测试特别是写好单元测试并不那么简单。要让自己的测试有模有样，还是有很多模式和原则需要遵守的。作者如是在短暂的实践之后马上奉上了一章TDD的概念与模式。在这一章不仅仅介绍了“夹具”、“测试替身”、“基于状态的测试”等基本名词概念，还给出了很多实用的技巧，比如三角法，就像几何中的三点确定一个平面，我们也用几个测试来固定一个产品代码。嗯，还有不能不提的测试驱动基本原则：1）、绝不跳过重构（如果没有重构这一环节，即使你有很完备的测试，还是会生产出很多糟糕的代码，因为使用测试驱动我们总是想尽快通过测试，甚至很少去思考设计上的问题） 2）、尽快变绿 3）、出错后放慢脚步（记得曾经在哪里看到过，敏捷就是慢的艺术，在写代码时切忌跑得过快，贪多，我们要做到每一步都胸有成竹，如果出错了不要紧，说明你走得太快了，放慢你的脚步）。如果你曾经试图过给已经写就的代码加单元测试，你会发现总有一些东西在阻碍你：继承（我们此时只关注子类，但父类很多的东西带来了累赘）、静态（static关键字修饰的东西或单件模式是一种紧耦合，很难使用测试替身替代，也很难模拟）。和开发产品代码一样，测试驱动也有很多很有用的模式，铭记这些模式会让你事半功倍。最后作者用很短的篇幅介绍了怎么在遗留代码上进行工作，如果你没时间阅读《修改代码的艺术》这本书，这里是个很不错的总结。第五、六、七、八章虽然前几章已经很精彩了，但是碰到有些具体场景你可能还是束手无策，发现前面几章的内容还是有点不够用。嗯，后面作者用了四章来阐述测试驱动在具体场景中如何工作：在web开发中如何和控制器一起工作？如何验证渲染的视图是不是正确的？如何使用测试驱动开发出DAO层？对于DAO层我们还是一如既往的使用模拟对象么？如果写集成测试我们该怎么做？有的时候我们经常会发现测试随机失败，这太让人气馁了，其实你是遇见了不可预测的问题，作者也准备了一章篇幅来介绍这些问题：与时间相关的问题，与多线程相关的问题。第五章介绍了web开发，第八章确实桌面开发了，如果你能给你的桌面应用写出很好的单元测试，说明你的桌面应用中业务逻辑也很好的与界面解耦了，这不是我们一直追求的么？呵呵。第九、十、十一章嗯，本书极具特色的一部分来了：验收测试。在这一部分讲解了用户故事，验收测试的工具验收测试的策略。实际上第三部分作者不仅仅是在讲解验收测试驱动开发，更是在谈论敏捷的开发方式，如果不想投入大把时间去看用户故事、敏捷计划等相关的专门书籍，本部分是一个很好的概览。后记就谈到这里吧。翻到书的封面发现英文标题Test Driven practical TDD and Acceptance TDD for Java Developers历历在目。哦，总算明白了出版社为什么要抛弃“实践”这个原名，披个艺术的马甲。 -
读罢《测试驱动开发的艺术》，忽然想起中国传统文化中的“道器之辩”。《易经》曰：形而上者谓之道，形而下者谓之器。中国的传统文化常常是重道轻器，认为道本器末，即道是根本，其他一切是道的外在表现，器是道的从生与从属。这就导致我们常常喜欢把“道”与“器”割裂开来，一味地重视过度抽象的“道”，进而形成一种形而上学的玄幻，使得“道”高高在上，未能落于实处。重道轻器给传统文化带来的缺失告诉我们，“道”与“器”应该是统一的，道是本质，却又必须依赖于器，受制于器。从软件开发的角度来看，TDD的本质思想即为“道”，这其中包括按照意图编程的思想，提高可测试性的设计原则，以及测试的模式与面向对象的基本思想。而“器”则包含对TDD的合理运用，针对不同的用例场景做出的测试手法，以及对测试工具的使用。本书第一部分《TDD入门》阐述的正是TDD之道。虽然是入门知识，却高屋建瓴地阐明了TDD的真谛。例如本书写道：在TDD周期中的第一步中，我们会写测试，实际上这并不只是写测试而已，而是在做设计。我们是在设计API，即用来访问新功能的接口。编码之前写测试，我们会自然地考虑新代码的调用方式。……测试先行的编码方式会促使我们站在代码用户（开发人员）的角度考虑，设计出更易用的API。很多开发人员并不愿意接受TDD的开发方式，认为这种先写测试后编码的方式既别扭而又浪费时间，原因就在于他们没有真正体会这种测试驱动设计的好处。TDD最重要的一个字眼儿就是drive（驱动），事实上，这种驱动力正是所谓“按照意图编程”的重要思想。意图编程，顾名思义，就是说写代码时先假设其他部分代码都已经存在了（即使事实并非如此）。使用这种编程方法时，我们可以把注意力集中在能有的，而不是已经有的东西上。使用意图编程，我们能让代码读起来更流畅，容易理解和使用，也能使代码清晰地表达出自己的本意，而不会过于强调实现细节。个人认为，本书第一部分给出的邮件模板子系统的范例更贴近开发真实，却又不至于晦涩难懂。作者在选择范例上的匠心独运，使得本书既具有很强的实践指导意义，又不至于陷入复杂的业务需求和技术细节中。范例给出的第一个测试、伪实现以及重构的手法，都是自然而然的TDD过程，而不是为了写作本书生拉硬拽，东拼西凑，有着强烈地雕琢痕迹。若能在阅读过程中，比照着这样的过程动手实验，相信能够获得更大的提高。从本书的第二部分开始，就迈入了TDD“器”的部分。之所以说是TDD之“器”，在于它介绍了针对特定技术应用TDD的内容，这其中包括对Web组件、数据访问、多线程、Swing代码的测试驱动开发。在讲解的过程中，作者还介绍了大量用于这些特定技术应用TDD的工具或框架，例如JspTest、EasyMock、MockObjects、HSQLDB、Jemmy、Abbot等。这些都是Java平台下常用的支持TDD的有力工具。本书的第三部分则着重介绍了ATDD（验收测试驱动开发），包括对用户故事的介绍，验收测试的特征与实现，ATDD的过程以及相关工具Fit。这在许多介绍TDD的书籍中都是不多见的内容。这两部分内容给出了许多贴近开发真实的例子，提出了许多卓有成效的测试方法。这些内容如此地实用，涵盖的知识如此地全面，基本上可以解决我们在企业开发中进行TDD可能遇到的问题。事实上，这些内容大多数都可以说是TDD实践过程中的拦路虎，尤其是针对表现层和多线程技术的TDD方法，大多数开发人员都缺乏这方面的知识，甚至因为这样而放弃TDD。本书极具实践指导意义的阐述弥补了这一空白。遗憾的是，本书介绍的内容主要针对Java开发人员，因而提及的工具也都基于Java平台，对于其他平台下的开发人员而言，无疑削弱了几分价值。本书还有一点不足就是“道”与“器”的不统一。前面提到，本书的第一部分开篇名义，用极简洁的语言道明了TDD的本质。然而本书的第二部分与第三部分，几乎只停留在TDD方法和工具的使用上，而忽略了测试对于设计的驱动力。书中的例子仅仅给出了如何完成测试用例，如果建立Mock对象，却不再介绍为何要这样编写测试用例，驱动我们进行设计的意图何在。换言之，后面的例子省略了驱动对设计进行推导的过程。这种驱动设计的能力恰好是很多程序员所不具备的。“器”固然重要，但它必须遵循“道”的要义，在其指引下实施。本书内容“道”与“器”兼顾，却将二者割裂开来，未能形成统一的整体，不能不说白璧微暇，略有遗憾。 -
读了《测试驱动开发的艺术》，总结一下有以下几个特点：1，名字“误人”这本书的名字有点过于炫了。应该讲这是一本写给Java开发人员的TDD的书籍，谈的更多的也不是艺术，而是实践。所以Java开发者会感觉更加亲切，也会觉得厚实。2，细致在讲解对于特定技术进行TDD实践方面，作者特别细致。从大的方面包括了对于Web组件、DAO、Swing、多线程等等继续TDD的内容。英文原版甚至还包括了对EJB部分。深入到某个专题，作者通过大量代码示例，分析不同情况，逐一阐述。比如讲解TDD数据访问层的时候，作者分别介绍了用纯JDBC，Spring的JdbcTemplate和Hibernate来实现DAO的时候，该怎么样进行TDD。同时也介绍了怎么样直接连接到内存数据库进行集成测试等。可谓无微不至。3，全面说这本书全面，是指它既介绍了TDD的概念，模式，对于特定技术的运用，同时还讲到了ATDD以及相关产品、策略和应用，可以说包罗万象。特别是ATDD部分，相关的中文出版书籍并不多，可以作为一个很好的入门材料，只是没有了介绍TDD那部分深入，却也留给了大家继续探索的空间。觉得有点美中不足的是，本书缺少一个贯穿始终的项目例子。如果有的话，可能读者会更身临其境。单元测试和TDD还是有本质的区别的。对于那些对TDD不是很熟悉的读者来说，本书的第一部分是很好的入门，第二部分则是很好的实践老师。当然，读这本书，并不轻松。跟之前读的几本图灵的书，比如《结网》、《与孩子一起学编程》相比，本书写得略显生涩，缺乏幽默——也许这就叫做严谨？
精彩短评 (总计41条)
-
只是看了前面的部分，感觉有比较好的操作性。根据书的描述，后续需要多实践。 -
前面几章很好，后面感觉稍差了点，整体来说是本好书 -
不错的书，包装完好，无破损。 -
很不错的书，有理论有例子，深入浅出。不搞 Java 所以只看了第一部分。博客水平的翻译很影响理解，后面专有名词多了根本就是灾难。几乎所有测试框架 API 都是英文的，“夹具”、“替身”……看着头晕。 -
书质量不错，送货也及时，昨天下雪路不好走，还是及时送到了。 -
纸张粗糙，字也不清楚，这本书不确认是否正版图书 -
好书，值得推荐。 -
实实在在的实践 -
书评在：http://www.ituring.com.cn/article/details/378 -
以前看的时候忽视了一点，那就是这种小步迭代，并不对实现代码有什么直接帮助。而是通过不断添加测试情景，明确代码功能的边界，保证代码的行为是收敛的。 -
测试驱动--开发 -
极限编程 - 测试驱动开发的艺术 -
这本书可能没有Kent Beck的《测试驱动开发》盛行，但是有几大精华的地方：Test Double的区别与应用场景；常见的单元测试模式；针对特定场景的TDD（Web组件，数据库，并发环境......）。 -
包装完整~送货快 -
一言以蔽之，写代码只为修复已失败了的测试 -
好书，挺满意 -
提供了一些较难测试的场景的测试方法 -
作为一本刚接触DTT的来说，教材内容不错，如果喜欢尝试DTT，推荐 -
比较详细的解说了如何使用TDD进行开发的过程，已经一些技巧和实用工具。本书以Java语言为切入点，主要说明如何在Java中使用TDD开发。但是前４章的基础，对于其他语言的开发者也很有用。由于本人不用Java开发，本书主要看了前４章的开发方法和技巧，以及一些工具的介绍，很高兴的了解了还有Mock这个方便测试的工具。对于TDD开发的方法，也学会了不少，值得推荐。 -
目前在项目中确实在大量实施TDD等单元测试开发, 但目前发现效果不好, 用例开发与测试方法不当. 需要更专业的意见.
在使用TDD过程中, 需要了解与学习所有涉及的技术点, 这样才能更好地将TDD运用与简单使用在具体项目中. 文中的具体技术的TDD测试框架有借鉴意义. -
这个书名真是…… -
选读完。TDD，先测试再编码再重构。好处有：
1.快速反馈。及早发现错误。
2.持续交付。易有成就感。
3.改进设计。因为先从用户和可测性角度出发。 -
这本书还不错，我觉得比kent beck的TDD讲的更让人易懂些。 -
敏捷开发经典 -
介于还行吧和推荐之间 -
单元测试的牛书。 -
除了讲了一般的tdd规则和方法外，作者也对一些难题（数据库、多线程、UI）做了实例演示，从该书中受益良多，特别是UI一章，在项目中，我成功的应用了MVP模式进行了农场开发的tdd，使得自己对tdd更加有信心了。 -
书名起的很吓人，但也就是一本入门书啦。重温了教科书版的用例设计，开发和重构原则，以及ATDD的介绍。 -
书包装不错..封皮也不错..内容更不错..挺好的..送货速度也很快.上午买的下午就到了..谢谢了 -
还是实践出真知，再看看书，理论上提高一下，挺好。 -
总得来讲，这本书的示例都很到位，只要跟着书的章节步骤完全写个遍代码都是没问题的，而且还给你更多的思考点，和解答。很不错。 -
书名无力吐槽……可以先把第 10 章开个头再回头看第 9 章，不然太痛苦…… -
TDD必备！ -
发货快，书的印刷很好，包装不错。 -
我不反对测试，但反对过度的测试。所以我一直对TDD抱有一丝的怀疑。
对于不涉及用户行为的代码，我们可以很容易的进行测试，使用TDD预先设定代码目标，免去持续发布的困扰，真的是一个不错的方案。
可是，现实的软件开发是一个极其复杂的事情！必然有用户行为，同时必然伴随着需求变更。这两点对于测试都是大忌。
书中针对带有界面的软件测试，也讲明相对纯代码较难处理，同时，也并没有给出完全的方案，感觉都是Hacker方式。
特别是目前较为复杂的前端，测试更是较难覆盖或者较难做到如后台纯代码方式的测试。 -
也没看完，看了一大半不想看了 -
虽然是JAVA的但必看，不亏艺术两字 -
从敏捷开发的角度来说，TDD一点都不敏捷，还没见过在真实项目开发中，有谁是先写测试再编码的。涉及到的一些概念很有启发。 -
对TDD是什么无感？看这本书可以帮你入门，里面写了个使用TDD的方法开发一个模板引擎的过程。还行吧 -
看了《TDD by example》、《测试驱动的面向对象开发》以及本书，这本书是三者中最实用的！解决了我使用TDD过程中的诸多疑惑和技术难点！ -
离心目中的软件工程师渐行渐远了，有些事还是存在于想象中的好。不过思维的东西还是各个领域通用的，多学点用的到的实践也挺好。SE的思想+XP的实践，恩，很实用的爱好。