测试驱动开发的艺术 pdf epub mobi txt 电子书下载 2026

简体网页||繁体网页

☆☆☆☆☆

出版者:人民邮电出版社

作者:Lasse Koskela

出品人:

页数:348

译者:李贝

出版时间:20101023

价格:59.00元

装帧:平装

isbn号码:9787115238368

丛书系列:图灵程序设计丛书·程序员修炼系列

图书标签:

测试驱动
敏捷开发
TDD
软件工程
计算机
编程
tdd
程序设计
测试驱动开发
敏捷开发
编程实践
软件工程
单元测试
开发方法
代码质量
持续集成
设计模式
自动化测试

下载链接在页面底部

facebook linkedin mastodon messenger pinterest reddit telegram twitter viber vkontakte whatsapp 复制链接

想要找书就要到小哈图书下载中心

qciss.net

立刻按 ctrl+D收藏本页

你会得到大惊喜!!

具体描述

在传统的软件开发中，开发人员对于代码是否正确心中无底，一切依赖于后期的测试环节。极限编程反其道而行之，主张采用测试驱动开发（TDD）的方法，即通过测试定义所要开发的功能的接口，然后实现功能的开发过程。TDD通过不断地测试推动代码的开发，既简化了代码，又保证了软件质量。

本书采用“手把手”的教学方式，通过大量实例来解释TDD，还专门用几章的篇幅来讲解如何为难于测试的技术编写单元测试。全书内容循序渐进，先侧重基础内容，讨论测试驱动开发和验收，然后进入动手实践部分，逐一讲解如何对各种技术应用TDD，最后介绍基于验收测试驱动的测试先行的方式构建完整的系统。

本书面向各个层次的Java程序员。面对变化的世界，请张开双臂，拥抱极限编程，拥抱TDD。

好的，这是一本关于软件架构与设计原则的图书简介，不涉及测试驱动开发相关内容，力求详实且自然： --- 《架构之维：从复杂性中提炼优雅的软件设计蓝图》内容简介在当今快速迭代的软件行业中，系统的规模和复杂性正以前所未有的速度增长。面对不断变化的需求和日益严峻的维护挑战，仅仅关注代码的实现已远远不够。成功的软件项目，其基石在于清晰、稳健且富有前瞻性的架构设计。本书并非探讨具体的编程语言特性或框架的用法，而是将视角提升到宏观层面，深入剖析构建可扩展、可维护、高性能系统的核心原则、权衡取舍与实践方法论。本书旨在为中高级软件工程师、技术负责人以及架构师提供一套结构化的思维框架，帮助他们驾驭复杂性，设计出能够穿越时间考验的软件蓝图。我们将深入探讨软件架构的本质——它如何应对变化，如何在不同约束条件下做出最优决策。第一部分：理解架构的基石与权衡本部分从基础理论出发，建立对“好架构”的共同理解。第一章：什么是软件架构？边界与关注点我们将首先厘清软件架构的真正含义，它不仅仅是组件图和部署图的堆砌。架构是关于关键决策的集合，这些决策一旦做出，就难以逆转。我们探讨架构师的角色，如何识别和定义系统的“非功能性需求”（质量属性），如性能、安全性、可伸缩性、可修改性等，并强调这些属性是驱动架构选择的核心动力。我们会详细分析常见的误区，例如过度设计和设计不足的危害，引导读者掌握在特定业务场景下寻找“恰到好处”的平衡点。第二章：设计原则的哲学深度：SOLID的更高层次解读 SOLID原则是模块化设计的基石，但本书将超越简单的代码示例，深入探讨这些原则在架构层面的体现。我们将分析如何通过“依赖倒置原则”来解耦宏观模块，如何应用“开放-封闭原则”来指导服务边界的划分，以及“里氏替换原则”如何影响继承结构和多态性实现。重点在于，这些原则不是孤立的规则，而是指导我们在系统演化过程中保持设计一致性的哲学指南。第三章：模块化与内聚性：划分系统的艺术有效的模块划分是控制复杂性的首要手段。本章将系统地介绍耦合（Coupling）和内聚（Cohesion）的量化与定性分析方法。我们将对比不同的模块化策略，例如基于领域、基于技术关注点或基于变更频率的划分。书中会引入“康威定律”的深刻洞察，阐述组织结构如何直接映射到系统架构，并提供反思组织结构以优化软件结构的实践步骤。第二部分：经典架构模式的深度剖析本部分将系统地解构当前主流的企业级架构范式，分析其适用场景、内在机制及潜在陷阱。第四章：分层架构的演进与局限从经典的四层架构（表示层、业务逻辑层、数据访问层）到更精细的三层或垂直切分，我们将剖析分层模型如何帮助隔离关注点。本章着重讨论分层架构在面对现代分布式需求时的挑战，特别是“透传问题”和“服务边界模糊”的现象，并提供优化分层设计以提高其生命力的策略。第五章：面向服务的架构（SOA）与微服务这是对分布式系统的核心探讨。我们将详细对比SOA与微服务的差异，超越单纯的“服务大小”之争，聚焦于治理模型、数据一致性策略（Saga模式）和通信协议的选择（REST, gRPC, 消息队列）。对于微服务，本书将重点探讨分布式事务处理、服务发现与注册、API网关的职责边界，以及如何避免服务蔓延导致的“分布式单体”陷阱。第六章：事件驱动架构（EDA）的威力与复杂度事件驱动范式代表了一种更加松耦合和响应式的设计思路。本章深入探讨了EDA的组件构成（事件发布者、事件代理/Broker、事件消费者）以及其核心优势——异步处理与状态解耦。我们将详述如何设计健壮的事件合约（Schema）、如何处理事件重放、幂等性问题，以及在事件链中如何维护可靠的业务流程，特别是对“最终一致性”的深入理解与管理。第三部分：跨越边界的架构决策本部分关注架构在非功能性需求驱动下的具体落地与演化。第七章：数据架构的策略选择数据是系统的核心资产，数据架构决定了系统的性能和可扩展性。我们将对比关系型数据库、NoSQL数据库（键值、文档、图、列族）的适用性，并探讨多数据存储策略（Polyglot Persistence）。本章重点解决数据一致性与可用性之间的权衡（CAP定理的实战应用），并深入讲解数据分片、复制策略以及CDC（变更数据捕获）在构建现代数据管道中的作用。第八章：可扩展性与弹性设计扩展性不仅仅是增加服务器数量。本章将区分垂直扩展、水平扩展，并详细介绍负载均衡策略（L4/L7）、无状态服务的设计哲学、缓存策略（本地缓存、分布式缓存如Redis/Memcached）的层次划分与失效策略。弹性设计方面，我们将探讨断路器、限流、熔断机制的原理，以及如何设计系统以优雅地应对依赖项的失败。第九章：架构演进与治理架构不是一次性完成的，它是一个持续演进的过程。本章聚焦于如何管理技术债务，何时以及如何安全地重构架构。我们将介绍“架构演进路线图”的制定，以及“架构评审”的有效实践。最后，本书将探讨如何建立和维护一套清晰的架构文档标准，确保架构愿景能够被整个团队准确理解和继承，实现从设计蓝图到实际部署的全生命周期治理。目标读者本书面向希望系统提升软件设计能力、构建面向未来的健壮系统的专业人士。无论您是经验丰富的后端开发者，渴望向架构师转型，还是正在领导团队进行系统重构的技术经理，本书都将为您提供经过实战检验的深刻见解和可操作的指导方针。 ---

作者简介

Lasse Koskela 程序员，软件开发培训师、咨询师，任职于芬兰知名软件公司Reaktor，致力于为客户提供软件性能提升解决方案；同时也是开源软件的忠实拥护者。其博客地址为：http://lassekoskela.com/thoughts/。

目录信息

第一部分 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
· · · · · · (收起)

读后感

评分☆☆☆☆☆

读了《测试驱动开发的艺术》，总结一下有以下几个特点： 1，名字“误人” 这本书的名字有点过于炫了。应该讲这是一本写给Java开发人员的TDD的书籍，谈的更多的也不是艺术，而是实践。所以Java开发者会感觉更加亲切，也会觉得厚实。 2，细致在讲解对于特定技术进行TDD实践方...

评分☆☆☆☆☆

敏捷软件开发-包括Extreme Programming 和Scrum等方法。其核心实践为--测试驱动 TDD：测试-->编码-->重构增量式开发验收测试驱动开发ATDD：我们会先写一个测试，然后再实现测试所描述的功能。ATDD的主要目的都是为了促进客户和开发团队之间的紧密协作。 TDD的三种主要工具...

评分☆☆☆☆☆

刚收到这本书的时候，匆匆翻了几页，觉得这本书的实用性会很强。当时稍稍有点忧虑，因为自己在遇到这本书之前，脑子里对测试驱动开发是没有多少概念的，这么强的实践性会不会给一个初入此门的人带来很多阅读上的障碍呢？待我慢慢地看完这本书，虽然很多细节性的实践方法还不能...

评分☆☆☆☆☆

用户评价

评分☆☆☆☆☆

这本书真是让人耳目一新，完全颠覆了我对传统软件开发的认知。作者的叙述方式非常引人入胜，仿佛带着读者一起走过了一段充满挑战又无比充实的学习旅程。书中对于TDD（测试驱动开发）的阐述深入浅出，从最基础的“红-绿-重构”循环，到如何设计出更具可测试性、更健壮的代码结构，每一步的讲解都扎实可靠。我尤其欣赏它对思维模式转变的强调，很多时候我们写代码是先想着功能实现，而这本书则引导我们反向思考：如何通过编写失败的测试来驱动功能的诞生？这种视角转换是学习过程中最宝贵的部分。书中提供的代码示例非常贴切实际，不是那种为演示而演示的晦涩例子，而是能直接在日常工作中应用的模板和思路。读完后，我感觉自己对代码的信心大大增强了，不再害怕修改老旧代码，因为心里有了一套行之有效的安全网。对于那些在复杂系统中挣扎的开发者来说，这本书无疑是一剂强心针，它教会的不仅仅是一种技术，更是一种严谨、优雅的工程哲学。它的价值在于将原本看似枯燥的测试工作，提升到了艺术创作的层面，让人在编写每一行代码之前都多了一份沉思。

评分☆☆☆☆☆

要用简短的文字来概括这本书带来的颠覆性影响是困难的，因为它更像是一次深入骨髓的思维重塑。我发现自己在写新功能时，习惯性地先在脑中构建出完整的测试场景，这极大地减少了后期的调试时间。作者对“依赖注入”和“控制反转”等设计模式在TDD环境下的实践应用讲解得极为透彻，解释了为何这些模式并非为了增加复杂度而存在，而是为了使代码更易于被隔离和测试。更重要的是，书中探讨了如何培养一种“测试文化”，这超越了单纯的技术操作层面，触及到了团队协作和质量承诺的核心。这种自下而上的文化变革，才是真正让TDD发挥最大效力的关键。阅读全书后，我感觉自己不再是那个被动修复Bug的“消防员”，而是主动塑造软件质量的“工匠”。这本书的价值在于，它提供了一条清晰的路径，指导我们如何将软件开发从一种容易出错的经验主义活动，提升为一种可预测、可验证的、真正意义上的工程学科。

评分☆☆☆☆☆

这本书的结构安排堪称教科书级别，逻辑流畅且层层递进，读起来没有任何跳跃感。它没有陷入过分纠结于某个特定语言或框架的细节中，而是聚焦于TDD背后的普适性原则和思维模型，这保证了其长久的参考价值。最让我印象深刻的是关于“测试的成本与收益分析”的讨论。作者非常坦诚地分析了在项目早期引入TDD可能带来的短期速度下降，但清晰地论证了这种“慢”是如何在长期维护、Bug修复和团队协作中带来指数级回报的。它为我们在项目管理层面上争取引入TDD提供了最有力的论据。与市面上很多只谈论“如何做”而不谈“为什么做”的书籍不同，这本书花了大量篇幅去探讨“为什么坚持这样做会更好”。它将测试视为沟通的桥梁，是团队之间关于代码契约的明确文档。对于那些对测试持怀疑态度的团队领导者，这本书可以作为一本极好的“布道”工具，因为它用无可辩驳的工程逻辑，解构了对TDD的常见误解和抵触情绪。

评分☆☆☆☆☆

这是一部写给那些真正想提升自己“内功”的工程师的宝典，它的深度远超一本普通的工具书。我特别欣赏作者在讨论测试的局限性和如何平衡快速迭代与完美测试覆盖率之间的权衡艺术。很多时候，我们被教导要追求100%的覆盖率，但这本书坦率地指出了这种做法的陷阱和不切实际之处，转而推崇基于风险和价值的测试策略。书中对“好测试”的定义非常到位，它不是简单地校验输入输出，而是包含了对设计意图的确认。阅读过程中，我数次停下来，对照自己目前负责的项目代码，反思当前的设计决策是否因为没有遵循TDD的约束而变得臃肿和难以维护。作者没有贩卖任何激进的理论，所有的论述都有坚实的实践基础作为支撑，读起来令人信服。它教会我们如何像建筑师一样思考软件的结构，确保地基（测试）先行，而不是在盖好楼层后才去补救。对于那些已经掌握了基础编程技巧，但总感觉代码“软绵绵”、缺乏内在韧性的开发者，这本书提供的洞察力是无价的。

评分☆☆☆☆☆

坦白说，起初我对“艺术”这个词抱持怀疑态度，以为又是那种故作高深的标题党。然而，随着阅读的深入，我逐渐理解了作者的良苦用心。这里的“艺术”并非指虚无缥缈的美学，而是指在严格的工程约束下，所能达到的最高效、最优雅的实践境界。书中对于如何处理遗留系统（Legacy Code）的章节尤为精彩，它没有采用一刀切的激进重构方式，而是提供了一套循序渐进、风险可控的“外科手术”流程。这种务实和审慎的态度，使得即便是最保守的团队也能逐步引入这些先进理念。我尤其喜欢其中关于“设计是测试的副产品”这一核心观点的阐述。它迫使我们将注意力从“我能写出什么功能”转移到“我如何能轻松地验证我写的东西”上来，这个焦点转移是实现高内聚、低耦合设计的催化剂。这本书的行文风格非常平实，没有过多的行业术语堆砌，使得即便是初级工程师也能跟上思路，而资深人士则能从中汲取关于架构思考的精髓。

评分☆☆☆☆☆

什么时间点适合开始看这本书呢？这是个问题。

评分☆☆☆☆☆

书名无力吐槽……可以先把第 10 章开个头再回头看第 9 章，不然太痛苦……

评分☆☆☆☆☆

以前看的时候忽视了一点，那就是这种小步迭代，并不对实现代码有什么直接帮助。而是通过不断添加测试情景，明确代码功能的边界，保证代码的行为是收敛的。

评分☆☆☆☆☆

很不错的书，有理论有例子，深入浅出。不搞 Java 所以只看了第一部分。博客水平的翻译很影响理解，后面专有名词多了根本就是灾难。几乎所有测试框架 API 都是英文的，“夹具”、“替身”……看着头晕。

评分☆☆☆☆☆

挺不错的tdd入门书，虽然里面说得技术有点老了