具体描述
本书介绍如何将各种TDD 最佳实践应用于Java 开发，主要内容包括：用Java 语言进行TDD 会用到的各种工具和框架，所需环境搭建；通过实际应用程序，展示TDD 优点及开发中应注意的主要问题；TDD是如何通过模拟内部和外部依赖来提升速度的；如何重构既有应用程序；详细介绍所有TDD 最佳实践。
作者简介
Viktor Farcic
资深软件架构师，Docker船长，Java开发专家，热衷于测试驱动开发、行为驱动开发、持续集成、持续交付和持续部署。
他把多年经验都分享在了博客上，深受读者欢迎：http://TechnologyConversations.com。
Alex Garcia
资深Java程序员，敏捷实践拥趸，热衷于学习新语言、新范式、新框架。
目录信息
1.1 为何要使用TDD 1
1.1.1 理解TDD 3
1.1.2 红灯?绿灯?重构 3
1.1.3 速度是关键 4
1.1.4 TDD并非测试方法 4
1.2 测试 5
1.2.1 黑盒测试 5
1.2.2 白盒测试 5
1.2.3 质量检查和质量保证的差别 6
1.2.4 更好的测试 6
1.3 模拟 7
1.4 可执行的文档 7
1.5 无需调试 9
1.6 小结 9
第2章 工具、框架和环境 10
2.1 Git 10
2.2 虚拟机 11
2.2.1 Vagrant 11
2.2.2 Docker 13
2.3 构建工具 14
2.4 集成开发环境 15
2.5 单元测试框架 16
2.5.1 JUnit 17
2.5.2 TestNG 19
2.6 Hamcrest和AssertJ 21
2.6.1 Hamcrest 21
2.6.2 AssertJ 22
2.7 代码覆盖率工具 23
2.8 模拟框架 24
2.8.1 Mockito 26
2.8.2 EasyMock 28
2.8.3 PowerMock 29
2.9 用户界面测试 29
2.9.1 Web测试框架 30
2.9.2 Selenium 30
2.9.3 Selenide 31
2.10 行为驱动开发 33
2.10.1 JBehave 33
2.10.2 Cucumber 35
2.11 小结 37
第3章 红灯?绿灯?重构——从失败到成功再到完美 38
3.1 使用Gradle和JUnit搭建环境 39
3.2 “红灯?绿灯?重构”过程 41
3.2.1 编写一个测试 41
3.2.2 运行所有测试并确认最后一个未通过 41
3.2.3 编写实现代码 42
3.2.4 运行所有测试 42
3.2.5 重构 42
3.2.6 重复 43
3.3 “井字游戏”的需求 43
3.4 开发“井字游戏” 43
3.4.1 需求1 44
3.4.2 需求2 49
3.4.3 需求3 52
3.4.4 需求4 57
3.5 代码覆盖率 58
3.6 更多练习 59
3.7 小结 60
第4章 单元测试——专注于当下而非过往 61
4.1 单元测试 61
4.1.1 何为单元测试 62
4.1.2 为何要进行单元测试 62
4.1.3 代码重构 62
4.1.4 为何不只使用单元测试 63
4.2 TDD中的单元测试 64
4.3 TestNG 64
4.3.1 注解@Test 64
4.3.2 注解@BeforeSuite、@Be- foreTest、@BeforeGroups、 @After Groups、@AfterTest和@AfterSuite 65
4.3.3 注解@BeforeClass和@AfterClass 65
4.3.4 注解@BeforeMethod和@AfterMethod 66
4.3.5 注解参数@Test(enable = false) 66
4.3.6 注解参数@Test(expected- Exceptions = SomeClass. class) 66
4.3.7 TestNG和JUnit差别小结 66
4.4 “遥控军舰”的需求 66
4.5 开发“遥控军舰” 67
4.5.1 创建项目 67
4.5.2 辅助类 69
4.5.3 需求1 69
4.5.4 需求2 72
4.5.5 需求3 74
4.5.6 需求4 75
4.5.7 需求5 77
4.5.8 需求6 80
4.6 小结 81
第5章 设计——难以测试说明设计不佳 82
5.1 为何要关心设计 82
5.2 Connect4 84
5.3 完成Connect4实现后再测试 85
5.3.1 需求1 85
5.3.2 需求2 86
5.3.3 需求3 87
5.3.4 需求4 88
5.3.5 需求5 89
5.3.6 需求6 89
5.3.7 需求7 90
5.3.8 需求8 91
5.4 使用TDD实现Connect4 92
5.4.1 Hamcrest 92
5.4.2 需求1 93
5.4.3 需求2 93
5.4.4 需求3 96
5.4.5 需求4 97
5.4.6 需求5 99
5.4.7 需求6 99
5.4.8 需求7 100
5.4.9 需求8 101
5.5 小结 103
第6章 模拟——消除外部依赖 104
6.1 模拟 104
6.1.1 为何使用模拟对象 105
6.1.2 术语 106
6.1.3 模拟对象 106
6.2 Mockito 107
6.3 “井字游戏”第二版的需求 107
6.4 开发“井字游戏”第二版 107
6.4.1 需求1 108
6.4.2 需求2 118
6.5 集成测试 124
6.5.1 分离测试 124
6.5.2 集成测试 125
6.6 小结 127
第7章 BDD——与整个团队协作 128
7.1 不同规范 128
7.1.1 文档 129
7.1.2 供程序员使用的文档 129
7.1.3 供非程序员使用的文档 130
7.2 行为驱动开发 130
7.2.1 叙述 131
7.2.2 场景 132
7.3 书店应用程序的BDD故事 133
7.4 JBehave 136
7.4.1 JBehave运行器 136
7.4.2 待定步骤 137
7.4.3 Selenium和Selenide 138
7.4.4 JBehave步骤 139
7.4.5 最后的验证 144
7.5 小结 146
第8章 重构遗留代码——使其重焕青春 147
8.1 遗留代码 147
8.2 编码套路 156
8.2.1 遗留代码处理套路 157
8.2.2 描述 157
8.2.3 技术说明 157
8.2.4 添加新功能 157
8.2.5 黑盒测试还是尖峰冲击测试 157
8.2.6 初步调查 158
8.2.7 应用遗留代码修改算法 161
8.2.8 提取并重写调用 166
8.2.9 消除状态的“基本类型偏执”坏味 170
8.3 小结 173
第9章 功能开关——将未完成的功能部署到生成环境 175
9.1 持续集成、持续交付和持续部署 175
9.2 功能开关 177
9.3 功能开关示例 178
9.3.1 实现fibonacci服务 181
9.3.2 使用模版引擎 184
9.4 小结 187
第10章 综述 188
10.1 TDD概要 188
10.2 最佳实践 189
10.2.1 命名约定 189
10.2.2 流程 191
10.2.3 开发实践 192
10.2.4 工具 195
10.3 这只是开始 196
10.4 这并非终点 196
· · · · · · (收起)
读后感
用户评价
收到您的要求，我将以一个读者的口吻，针对您指定的书名《Java测试驱动开发》，撰写五段风格各异、内容丰富的图书评价。请注意，这些评价将是**虚构**的，旨在展示不同读者的视角，且**不会**提及书中的具体内容，而是侧重于阅读体验、期望落差或总体感受。 --- 这本书，说实话，我拿到手的时候，心里是带着一种近乎虔诚的期待的。毕竟在这个“重开发、轻测试”的行业乱象里，能看到一本专注于TDD实践的书籍，简直像是沙漠里看到绿洲。我原本的设想是，这本书会像一本武功秘籍，把如何用TDD的红灯-绿灯-重构的循环，融入到实际的Java项目结构中去，特别是对于那些复杂的业务逻辑，它应该能提供一套行之有效的、可复用的代码结构范例。我期待看到的是，作者如何用最简洁、最优雅的JUnit 5或Mockito语法，来模拟那些令人头疼的第三方服务调用和数据库交互。然而，阅读过程中，我更多的是感觉到了一种“理论的堆砌感”。书中的章节组织虽然清晰，但总像是隔着一层毛玻璃在看实战。我花了大量时间去揣摩那些抽象的概念，而不是直接上手敲代码解决实际问题。这就像是学游泳的书，理论知识讲得头头是道，但真正下水时，你还是得自己摸索换气节奏。对于一个迫切想提升代码质量的开发者来说，这种偏重于“是什么”而非“怎么做”的叙述方式，着实让人在实践层面感到一丝迷茫。期望落差主要在于，它更像是一本课程大纲，而非一本操作手册。
说实话，这本书的行文风格是极其平稳的，甚至可以说有点“教科书式”。它很少有那种让人眼前一亮、拍案叫绝的“黑客技巧”或者独创的测试模式分享。我更欣赏那些敢于打破常规、提出挑战性观点的技术书籍。阅读这本书的过程，就像是沿着一条铺设得非常平整的柏油马路行走，安全、舒适，但缺乏沿途的惊喜。我一直在寻找作者在面对企业级项目中那些绕不开的“遗留代码”和“同步依赖”时，是如何运用TDD思想进行改造和治理的实战案例。因为理论上谁都懂TDD的好处，但真正难的是如何在一个已经成型的、缺乏测试覆盖的系统里，以一种不至于让产品发布停滞的方式，逐步引入测试驱动的思维。这本书似乎避开了这些“泥泞”的地带，专注于构建一个理想化的、从零开始的环境。这使得对于我这样主要负责系统维护和重构的工程师而言，这本书的“即时应用价值”打了折扣。我更需要的是那种“如何在烂摊子里开垦”的智慧，而不是“在完美草地上播种”的教程。
这本书的排版和装帧，坦白讲，是相当有质感的，拿在手上沉甸甸的，很有分量感。从封面设计到内页字体选择，都透露着一种专业和严谨的气息，这点是值得肯定的。我是一个视觉驱动型的学习者，高质量的实体书能极大地提升我的阅读动力，这本确实做到了这一点。最初翻阅时，我关注的焦点是它的“深度”和“广度”的平衡。我希望它能覆盖从单元测试、集成测试到更高级别的契约测试，特别是针对Spring Boot等主流框架下的依赖注入和AOP切面的测试策略。但是，在阅读过程中，我发现它似乎更倾向于在基础概念上做大量的铺垫，对于那些资深开发者急需的“疑难杂症”的处理经验，描述得相对保守和笼统。很多时候，我感觉我需要额外的搜索工具去验证书中的一些观点是否在当前主流的版本和生态中依然适用。比如，对于Mocking策略的选择，到底是倾向于使用PowerMock的“侵入式”还是纯粹的接口Mock，书中似乎没有给出足够有力的、基于案例的对比分析。整体感觉是，它为初学者打下了一个坚实的地基，但对于想在测试领域“筑高楼”的人来说，工具箱里的高级组件似乎被藏在了不起眼的地方。
这本书在引入新的测试工具或框架时的节奏把握，是我个人体验中比较困惑的一点。我理解任何技术书籍都需要介绍背景和工具链，但在这本书中，某些章节似乎花了过多的篇幅去介绍那些我早已熟稔于心的基础类库，而对于那些新兴的、能显著提升测试效率的库，比如异步测试框架的最新进展或者并行测试的深度优化，介绍得又显得过于简略，像是走马观花。这种“失衡”让我觉得在阅读时间分配上有些不合理。我希望一本专注于“开发”的书，能更贴近现代Java生态的脉搏，尤其是考虑到当前微服务架构下，对隔离性和快速反馈的需求越来越高。测试的瓶颈往往不在于写多少断言，而在于如何快速、稳定地启动和隔离测试环境。如果这本书能更深入地探讨Docker在测试环境搭建中的集成，或者探讨如何构建健壮的测试数据工厂，而不是仅仅停留在`@BeforeEach`的层面，那它的实用价值无疑会大大提升。这更像是一本关于基础工具集成的指南，而非一套完整的测试战略规划书。
从整体的阅读体验来看，这本书像是一次非常严谨的学术报告，而非一次热烈的技术分享会。作者的逻辑链条是无懈可击的，每一个论点都有充分的论据支撑，论述过程严密到几乎没有歧义。然而，技术学习有时候需要的恰恰是那种“跳出框框”的思维刺激。我期待能看到一些作者个人独特的测试哲学，比如他们对“测试是否应该模拟一切”这种核心争论的倾向性观点，以及基于这种观点所做出的设计取舍。书中虽然涵盖了各种测试的类型，但那种强烈的“作者声音”和“个人烙印”是比较缺失的。这导致我读完之后，感觉自己知识结构更加规整了，但内心的“技术热情”却没有被点燃。我需要的是能激发出我主动去挑战当前测试实践的动力，而不是仅仅告诉我行业内的“最佳实践”是什么。因此，对于那些已经有一些测试经验，希望寻求突破和变革的读者来说，这本书可能提供的“增量价值”不如预期中那么爆炸性。它巩固了基础，但未能在高阶思维层面带来足够的启发。
TDD的话整本书看第三章就足够了。比较偏实操，但是例子真的是有点太简单。希望有更多更复杂一些的例子。bdd的东西还是让我有比较直观的感受，但是针对的是web页面的，纯后台的要怎么做呢？文章的一些观点还是有点意思的，排版也还不错，阅读起来还比较舒服。以后要多实践TDD了。
非常好的介绍TDD的书籍，实践性也对新手友好！如果想深入了解TDD相关的各个领域，可以看本书推荐的论文和相关书籍
道理我都懂，但是谁在实际场景用了。。
非常好的介绍TDD的书籍，实践性也对新手友好！如果想深入了解TDD相关的各个领域，可以看本书推荐的论文和相关书籍
四天花早上的时间读完，没有太大收获，我也体会不了为什么要用tdd
