具体描述
测试驱动开发(TDD)的实践已经帮助众多软件开发人员提高了软件开发的质量、敏捷性、生产力和速度，《测试驱动数据库开发》将展示如何对TDD进行调整，以便在数据库设计与开发工作中获得同样强大的优势。《测试驱动数据库开发》共4个部分，全面介绍测试驱动数据库开发(TDDD)技术。第1章至～第4章重点讨论数据库的类的基本概念，第5章至第9章讨论如何用面向对象的方式来精益地做数据库的类的设计以及修复设计的错误，第10章至第13章讨论使用mocking和重构来应对由传统方法开发出来的遗留数据库的两种方法，第14章和第15章讨论如何使一个数据库应用系统能够满足不同客户的不同需求，以及如何将本书的技术运用到其他数据持久化方案之中。
《测试驱动数据库开发》适合没有接触过测试驱动开发且正在开发规模较大、需求多变的数据库应用系统的开发人员和架构师阅读，同时也适合尚未在持久化层运用测试先行开发技术的测试驱动开发爱好者阅读。
作者简介
Max Guernsey, III
Hexagon软件公司的管理成员，他以该公司作为一个平台，将真正的数据库和用户界面的敏捷性引入到那些已经在中间层采用了敏捷软件开发方法的组织之中。他有十余年的软件开发经验，其中大部分经验是在敏捷软件开发的环境中获得的，这期间的几乎一半时间，他一直就敏捷和测试驱动数据库开发主题，写博客、写作和发表演讲。通过Net Objectives，他开设“数据库敏捷培训”这样一门开创性的课程，该课程专注于频繁、安全和毫无痛苦地变更数据库设计所需的关键的技术技能。他的博客maxg3prog.blogspot.com。
伍斌
独立匠艺程序员。专注于测试驱动开发、驯服烂代码及编程操练。除翻译本书外,还在撰写《驯服烂代码》和《会运行的文档》两本书。自从1993年大学毕业以来,先后做过程序员、测试工程师、项目经理和软件开发咨询师。2013年4月创办公益编程操练社区“bjdp.org北京设计模式学习组”。个人网站wubinben.com，微信公众号bjdp_org。
目录信息
1.1 为何改变书的内容 1
1.1.1 每天敏捷都在逐步地入侵我们的领域 2
1.1.2 若没有TDD敏捷就没有成效 2
1.1.3 在数据库领域运用TDD是个挑战 3
1.2 谁是目标读者 3
1.2.1 TDD和OOP 3
1.2.2 应用程序和数据库 4
1.3 什么是障碍 4
1.3.1 数据库就是对象 4
1.3.2 TDD适用于类，不适用于对象 4
1.3.3 我们需要数据库的类 5
1.4 小结 6
第2章 建立数据库的类 7
2.1 TDD中类的角色 7
2.1.1 可靠的实例化过程 7
2.1.2 测试检查对象 8
2.2 面向对象编程语言中的类 8
2.2.1 类的构建很容易：构建新对象即可 8
2.2.2 一条途径：必要时析构 9
2.3 数据库的类 9
2.3.1 两条途径：创建或改变 10
2.3.2 难点：统一两条途径 10
2.3.3 真实的数据库的生长情况 11
2.3.4 将每个数据库构建成生产数据库会怎么样 11
2.3.5 所有数据库都遵循完全相同的途径 12
2.4 增量构建 12
2.4.1 用文档记录每一次数据库的变更 12
2.4.2 标识当前版本 13
2.4.3 根据需要依次实施变更 13
2.5 实现 13
2.5.1 需求 13
2.5.2 数据库实例化机制的伪代码 14
2.5.3 输入的伪代码 14
2.6 小结 14
第3章 讲一点TDD 16
3.1 测试先行的技术 16
3.1.1 编写测试代码 17
3.1.2 让测试失败得有一些有价值的启示 19
3.1.3 看到测试运行通过 19
3.1.4 重复 20
3.2 测试即规格 21
3.2.1 “测试不是测试，而是规格” 21
3.2.2 “测试不是规格，而是测试” 22
3.2.3 测试是可运行的规格 22
3.2.4 增量设计 24
3.3 构建良好的规格 24
3.3.1 规定行为，而不是结构 24
3.3.2 从一无所有开始驱动设计，而不是从其他方式开始 25
3.3.3 从内向外地定义设计 25
3.3.4 从外向内地定义设计 27
3.4 小结 29
第4章 安全地改变设计 31
4.1 什么是安全 31
4.1.1 违约有点糟 32
4.1.2 丢失数据可能会让你被炒鱿鱼 33
4.1.3 不改设计也同样危险 34
4.2 解决方案：过渡测试 37
4.2.1 测试驱动的实例化 37
4.2.2 建立过渡测试 38
4.2.3 累加变化的过渡测试 40
4.2.4 过渡测试的变形 44
4.2.5 为什么不使用公共接口 49
4.3 过渡保障 49
4.3.1 Read/Read过渡测试 49
4.3.2 每次升级时通过数据库的类来运行 52
4.3.3 备份和失败时回滚 53
4.3.4 让过渡测试充分利用过渡保障 53
4.4 小结 54
第5章 遵循接口 55
5.1 接口的优势 55
5.1.1 更强的耦合语言 56
5.1.2 弱耦合的语言 57
5.1.3 共识 57
5.1.4 耦合到数据库的类 58
5.1.5 问题是发生了重复 58
5.2 像客户对象般的遵循 58
5.2.1 创建DatabaseDesign类的需求 58
5.2.2 规定DatabaseDesign类 60
5.2.3 摆脱使用多个客户端平台时出现的重复 61
5.2.4 当耦合出问题时会发生什么 62
5.2.5 消除数据库构建和客户端代码之间的重复 62
5.2.6 解除实现与设计之间的耦合 63
5.3 症结：变更 64
5.3.1 随时间而变化的设计 64
5.3.2 记录所有版本的设计 65
5.3.3 耦合到设计的正确版本 68
5.4 症结：耦合 69
5.4.1 不同的客户端耦合到不同的版本 69
5.4.2 总是不得不修改所有东西也是重复 69
5.4.3 透镜概念介绍 73
5.4.4 虚拟透镜 76
5.4.5 “当前”透镜 78
5.4.6 “新”透镜 79
5.5 小结 81
第6章 定义行为 82
6.1 一组新问题 83
6.1.1 无封装 83
6.1.2 隐藏一切 84
6.1.3 数据库中的业务逻辑 84
6.2 知识、信息与行为 85
6.2.1 通告 86
6.2.2 知识 88
6.2.3 行为 90
6.3 由外而内地开发 92
6.3.1 定义测试 93
6.3.2 生长出接口 94
6.3.3 生长出行为和结构 95
6.4 用规格来实现合理的设计 97
6.4.1 开发当下的需求，而不是将来的需求 97
6.4.2 用增量的方式构建 98
6.4.3 将访问限定在规定的内容上 98
6.4.4 小结 99
第7章 为可维护性而构建 100
7.1 再也不要担心未来 100
7.1.1 在当下寻找机会 101
7.1.2 针对通告进行设计 102
7.1.3 使用行为来翻译通告和知识 106
7.2 用激情和热忱来保护知识 108
7.2.1 不做改变是最危险的选择 108
7.2.2 让设计保持自然 110
7.3 当事情在未来发生时再处理 111
7.3.1 定义新的设计 111
7.3.2 引入最小的变化 113
7.3.3 让测试运行通过 115
7.3.4 停下来，思考，重构 117
7.3.5 小结 119
第8章 错误与修复 121
8.1 各种错误 121
8.1.1 轴：好的错误还是坏的错误 122
8.1.2 轴：错误发布了没有 124
8.2 处理好的错误 125
8.2.1 修复它就好了 125
8.2.2 现在就记录行为 126
8.2.3 回溯功能的根源 128
8.3 处理坏的错误 129
8.3.1 未发布的错误 129
8.3.2 已发布的错误 133
8.3.3 灾难性的错误 139
8.4 小结 140
第9章 设计 141
9.1 结构与设计 142
9.1.1 结构：执行细节 142
9.1.2 测试和类信息 144
9.2 什么是设计 144
9.2.1 概念之桶 145
9.2.2 真正的TDD中强制性的部分 147
9.3 组合与聚合 148
9.3.1 组合：一件事有多个组成部分 148
9.3.2 聚合：连接截然不同的东西 151
9.4 复用 154
9.4.1 避免将同样的内容开发两遍 154
9.4.2 通过组合或聚合来实现复用 156
9.5 抽象 157
9.5.1 发现运用抽象的机会 157
9.5.2 封装行为 159
9.5.3 寻找各种方式来允许变化发生在依赖关系中 164
9.5.4 处理时间问题 165
9.6 小结 169
第10章 mocking 171
10.1 测试单个的行为 171
10.1.1 为什么封装 172
10.1.2 测试就是对那些在其控制之外的一切进行测试 172
10.1.3 从测试那里来控制不相关的行为 173
10.1.4 mocking控制了行为 174
10.2 在面向对象编程中的mocking 174
10.2.1 设置 175
10.2.2 解耦 179
10.2.3 隔离 181
10.2.4 集成 182
10.3 在数据库设计中使用mocking 182
10.3.1 示例问题 183
10.3.2 示例解决方案 184
10.3.3 组合 187
10.3.4 聚合 188
10.3.5 为可测试性而设计 188
10.4 小结 189
第11章 重构 190
11.1 什么是重构 190
11.1.1 改变设计但不改变行为 191
11.1.2 在测试运行通过的背景下 192
11.2 较低和较高风险的设计变更 199
11.2.1 较低风险：改变类一级的设计 199
11.2.2 中等风险：重新安排行为的逻辑 200
11.2.3 较高风险：改变知识的容器 202
11.2.4 这不是一个跳过测试的邀请 202
11.3 小结 202
第12章 遗留数据库 203
12.1 提升到一个类 203
12.1.1 推导初始版本 204
12.1.2 用测试来钉牢过渡行为 206
12.2 控制耦合 207
12.2.1 识别和锁定现有的使用数据库的情况 207
12.2.2 按需封装 209
12.3 控制变更 210
12.3.1 用测试驱动新的行为 210
12.3.2 按需钉牢构造行为 212
12.3.3 按需钉牢行为 213
12.3.4 实现新的行为 214
12.4 查找接缝和组件 215
12.4.1 查找接缝 215
12.4.2 封装组件 218
12.5 小结 222
第13章 Fa?ade模式 224
13.1 使用Fa?ade的封装 224
13.1.1 Fa?ade模式的说明 225
13.1.2 测试驱动开发出来的新的Fa?ade数据库 229
13.1.3 使用组合方法的替代方案 235
13.1.4 封装还是不封装 235
13.2 扼杀旧接口 236
13.2.1 将正在改变的行为转移到Fa?ade 236
13.2.2 当不再需要时删除访问权限和功能 237
13.3 在Fa?ade数据库中对行为进行测试驱动开发 238
13.3.1 暴露遗留的行为 238
13.3.2 做事情的另一种方法 239
13.3.3 新的行为 239
13.4 小结 241
第14章 变奏曲 242
14.1 重要的是拥有一个类，而不是实现 243
14.2 场景：跳过那些步骤 243
14.2.1 问题 243
14.2.2 解决方案 244
14.2.3 正确的工作量 246
14.3 偏离 246
14.3.1 问题 246
14.3.2 解决方案 247
14.3.3 应用解决方案 248
14.4 通用的解决方案 252
14.5 小结 252
第15章 其他应用 254
15.1 XML 255
15.1.1 封装 255
15.1.2 XSD Schema 255
15.1.3 XSLT过渡 257
15.1.4 对XSLT的变更进行过渡测试 258
15.2 文件系统和其他的对象目录 259
15.2.1 对文件系统的操作进行过渡测试 259
15.2.2 Shell脚本过渡 261
15.3 数据对象 262
15.3.1 类的定义就是Schema 262
15.3.2 对Ugrader类进行过渡测试 263
15.3.3 编写过渡 266
15.4 小结与寄语 270
· · · · · · (收起)
读后感
用户评价
阅读《测试驱动数据库开发》这本书，我最先被吸引的是它所提出的“测试驱动”这一核心概念。在许多其他领域，TDD（Test-Driven Development）已经广为人知，并被证明是一种非常有效的开发方法。但将这一理念应用到数据库开发上，却是我第一次接触。我的好奇心被极大地激发了。在我过去的数据库开发经历中，测试往往是在编码完成后才进行的，而且主要是功能性的验证。这种滞后的测试方式，导致了许多潜在的问题直到后期才暴露出来，修复起来费时费力，甚至可能影响项目进度。因此，我非常期待这本书能够详细阐述如何在数据库开发的早期就引入测试，如何通过编写测试用例来指导数据库的设计和实现。我希望书中能提供具体的实践指导，例如，如何设计能够覆盖各种边界条件和异常情况的数据库测试？如何编写能够验证数据完整性、一致性和性能的测试？书中是否会介绍一些支持数据库 TDD 的工具或框架？我希望这本书能够提供一套系统的方法论，让我能够理解并掌握如何在数据库开发过程中，利用测试来驱动代码的编写，从而提高代码质量，降低 bug 率，最终构建出更加稳定可靠的数据库系统。
这本《测试驱动数据库开发》的封面设计本身就给我一种严谨而专业的印象，深蓝色调搭配银色文字，仿佛预示着这本书将带领我深入探索一个系统化、科学化的数据库开发领域。我之所以选择它，很大程度上是因为我在日常工作中，对于如何更高效、更健壮地构建和维护数据库系统感到有些力不从心。传统的开发模式往往是在编码完成后才进行测试，这样一旦发现问题，修改起来往往牵一发而动全身，不仅耗时耗力，还容易引入新的bug。这本书的“测试驱动”理念，就像是一盏明灯，指引我看到了另一种可能性：在编写代码之前，先编写测试用例，用测试来驱动代码的开发。这听起来有点反直觉，但我对它所承诺的能够极大地提升代码质量、减少返工、甚至最终降低开发成本的可能性充满了期待。我特别想了解书中是如何具体阐述这个流程的，比如如何设计那些有指导意义的测试用例，以及如何将这些测试集成到整个开发生命周期中。此外，书中是否会涉及到一些具体的工具和框架来支持这种开发模式？我对这方面的实践指导非常渴望，希望这本书能够提供一套清晰可行的路线图，让我能够循序渐进地掌握这项技能，从而在未来的数据库开发项目中，能够更加从容自信地应对挑战，构建出真正稳定、可靠、易于维护的数据库解决方案。我甚至设想，通过这种方式，我们团队的整体开发效率和产品质量都能得到质的飞跃。
初次看到《测试驱动数据库开发》这本书的标题，我就被它所蕴含的创新理念所吸引。在我的认知里，测试驱动开发（TDD）在应用层和业务逻辑层已经非常成熟，但将其精髓应用于数据库开发，我从未深入实践过。我始终认为，数据库作为应用系统的基石，其稳定性和健壮性至关重要，而传统的开发模式往往难以避免后期才发现的深层问题。因此，我对于这本书将如何指导开发者在数据库设计和实现之初就引入测试，从而“驱动”代码的编写，充满了极大的好奇。我非常希望书中能够提供详实的案例和具体的技术细节，展示如何为数据库的 Schema、数据迁移、存储过程、视图等编写有效的测试用例。我特别想了解书中是否会涉及如何进行数据库的单元测试、集成测试，甚至是在开发早期就进行性能和安全方面的压力测试。我期待这本书能够提供一套完整的、可落地的方法论，让我能够理解并实践“先测试，后编码”的数据库开发模式，从而显著提升数据库的质量，减少调试时间，最终构建出更加可靠、高效且易于维护的数据库系统。
这本《测试驱动数据库开发》的出现，对我而言，简直就像是为我长久以来在数据库开发中的一些困惑提供了一剂良方。我一直觉得，数据库的开发过程，尤其是其测试环节，似乎总有些“后知后觉”。我们通常是先写好 SQL 语句，写好存储过程，然后才去验证它是否满足需求，是否能高效运行。这种模式，一旦出现问题，往往需要花费大量的时间去回溯和调试，那种沮丧感我深有体会。所以，“测试驱动”这个概念，对于数据库开发而言，听起来就充满了革命性。我迫切地想知道，这本书是如何将这个理念具体落地。书中会详细讲解如何设计出那些有指导意义的数据库测试用例吗？这些测试用例如何能够有效地覆盖数据库的各种结构，比如表、索引、约束，以及各种逻辑，比如存储过程、触发器？我希望书中能够提供一些实操性的建议，比如如何使用特定的工具来编写和执行这些数据库测试，以及如何将这些测试集成到持续集成（CI）的流程中，从而实现自动化测试。我憧憬着通过这本书的学习，能够彻底改变我以往的开发习惯，让我能够以一种更主动、更严谨的方式来开发数据库，最终构建出真正高质量、高可靠性的数据库系统。
这本书的标题《测试驱动数据库开发》让我眼前一亮，仿佛打开了一扇通往更高效、更严谨的数据库开发模式的大门。在我过往的开发经历中，数据库的测试往往是后期才进行的，并且往往是功能性的验收测试，很多潜在的问题直到上线后才暴露出来，修复起来异常艰难。因此，我非常期待这本书能够提供一种全新的视角和方法论，将测试融入数据库开发的每一个阶段。我希望书中能够详细阐述如何设计出能够驱动数据库代码开发的测试用例，例如，如何编写能够验证数据库 Schema 定义、数据约束、甚至存储过程逻辑的单元测试。我更关心的是，书中是否会提供关于如何进行集成测试和性能测试的实用技巧，以及如何将这些测试自动化，使其成为CI/CD流程中的一部分。这本书是否会推荐一些特定的工具或框架来支持这种开发模式？我渴望从中学习到一套系统性的实践方法，能够帮助我构建出更加健壮、稳定、易于维护的数据库系统，从而在日后的工作中，能够更加自信地应对各种挑战，交付高质量的数据库解决方案。
我对《测试驱动数据库开发》这本书的兴趣，源于我对数据库开发中“质量保障”这一环节的持续关注。在我过往的工作经验中，数据库的 bug 往往是系统中最难缠、最难定位的那一类，它们常常表现为数据不一致、性能瓶颈，甚至数据丢失，这些都可能带来灾难性的后果。因此，我一直渴望找到一种更有效的方法来预防这些问题的发生。当看到“测试驱动”这个词汇时，我立刻联想到它在应用开发中的巨大成功。我非常好奇，如何才能将这种“先测试，后开发”的理念，真正地应用到数据库层面。我希望这本书能够提供一套系统性的方法论，指导我如何设计出能够有效覆盖数据库 Schema、数据模型、存储过程、视图等各种组件的测试用例。我尤其关注书中是否会深入探讨数据库单元测试、集成测试，以及如何构建自动化测试流程，以确保数据库代码的质量和稳定性。这本书是否会介绍一些实用的工具或框架，来辅助开发者进行数据库的测试驱动开发？如果能够获得这些方面的深入指导，我相信这本书将极大地提升我构建健壮、可靠、易于维护的数据库系统的能力，为我带来全新的开发视角和实践体验。
在我看来，数据库是整个软件系统中最核心、最底层但又最容易被视为“黑盒”的部分。许多开发者可能更专注于上层的业务逻辑，而对数据库的设计、优化和测试重视不足，这往往导致项目后期出现难以解决的bug。因此，《测试驱动数据库开发》这本书的标题就极大地吸引了我。我尤其对“测试驱动”这个概念在数据库领域的应用充满好奇。在我以往的开发经历中，数据库的测试往往是滞后的，而且通常只关注功能性的验证。我非常期待这本书能够提供一套完整的、可操作的方法论，指导开发者如何在数据库开发的早期就引入测试，如何通过编写高质量的测试用例来驱动数据库的设计和代码实现。我希望书中能够详细讲解如何针对数据库的 Schema、存储过程、触发器等编写单元测试，如何进行有效的集成测试，以及如何将这些测试无缝集成到自动化构建和部署流程中。我对书中可能介绍的自动化测试工具和框架也抱有浓厚的兴趣，期望它能为我提供一套系统性的解决方案，让我能够构建出更加健壮、稳定且易于维护的数据库系统，从而显著提升项目的整体质量和开发效率。
作为一名对数据库技术充满热情的研究者，我一直致力于寻找能够优化数据库开发流程、提升系统可靠性的方法。当我在书店看到《测试驱动数据库开发》这本书时，我的兴趣就被立刻点燃了。我深知，在软件开发领域，测试驱动开发（TDD）已经成为一种被广泛认可的高效实践。然而，将 TDD 的理念成功地应用到数据库开发中，却是一个充满挑战且意义重大的课题。我非常好奇书中是如何解决这一挑战的。我希望这本书能够深入探讨 TDD 在数据库领域的具体落地，包括如何设计能够有效指导数据库结构、数据模型、甚至存储过程编写的测试用例。我尤其关注书中是否会提供关于如何进行数据库单元测试、集成测试以及性能测试的详细指导，以及如何将这些测试无缝集成到持续集成/持续部署（CI/CD）的流程中。此外，我对于书中可能介绍的用于支持数据库 TDD 的自动化工具和技术栈也充满期待。如果这本书能够提供一套系统性的理论框架和可操作的实践指南，我相信它将极大地提升数据库开发的自动化水平和质量保障能力，为构建更加健壮、可维护的数据库系统提供有力的支撑。
这本书的标题《测试驱动数据库开发》本身就极具吸引力，尤其对于我这样一名在数据库领域摸爬滚打多年的开发者来说。我一直在寻找能够提升数据库开发效率和质量的更优方法，而“测试驱动”这个词汇，一下子就抓住了我的注意力。在我看来，传统的数据库开发往往侧重于功能实现，而对测试的重视程度相对较低，这导致了很多问题在项目后期才暴露出来，修复成本极高。我非常渴望了解，如何将“测试驱动”的理念真正地应用到数据库开发中。这本书是否会提供一套切实可行的流程，指导我如何从编写测试用例开始，逐步构建数据库的 Schema、存储过程、触发器等？我希望书中能够深入探讨如何设计出能够有效覆盖各种场景的数据库测试，包括单元测试、集成测试，甚至性能测试。我期待书中能够提供具体的代码示例和技术细节，让我能够清晰地理解如何在实际项目中应用这些方法。这本书是否会涉及到一些自动化测试工具或框架，能够帮助我更高效地执行数据库测试？如果能够获得这些方面的指导，我相信这本书将对我未来的数据库开发工作产生深远的影响，让我能够构建出更加健壮、稳定且易于维护的数据库系统。
我一直认为，数据库是整个应用程序的灵魂，但恰恰也是最容易被忽视或者被当作“黑盒”对待的部分。很多开发者可能更专注于上层的业务逻辑，而对数据库的设计、优化和维护了解有限。这本《测试驱动数据库开发》的出现，在我看来，正是填补了这一重要的知识空白。我尤其对书中“测试驱动”这一核心理念感到好奇。在我的经验中，数据库的测试往往是滞后的，而且往往是功能性的测试，很少有针对数据库结构本身或者性能的早期、持续的测试。如果这本书能够真正地将测试前置，将测试作为开发过程中的一个重要驱动力，那么这将彻底改变我以往的开发习惯。我希望书中能够深入剖析测试驱动开发在数据库领域的具体实践，不仅仅是理论上的阐述，更重要的是提供一些切实可行的技术方法和流程。例如，书中会讲解如何针对数据库的 Schema 设计编写单元测试？如何模拟高并发场景下的性能测试？如何确保数据的一致性和完整性？这些都是我在实际工作中常常遇到的难题，如果这本书能够提供有效的解决方案，那将是极其宝贵的。我期望这本书能够为我提供一套完整的体系，让我能够系统地学习如何将测试思维融入数据库开发的每一个环节，从而构建出更加健壮、更易于维护的数据库系统。
翻译让人看不懂，也许也是我理解不了吧。
写的可操作性太差了
翻译让人看不懂，也许也是我理解不了吧。
写的可操作性太差了
写的可操作性太差了
