第1章　为何改变书的内容、谁是目标读者和什么是障碍　
　1.1　为何改变书的内容　
　1.1.1　每天敏捷都在逐步地入侵我们的领域　
　1.1.2　若没有TDD敏捷就没有成效　
　1.1.3　在数据库领域运用TDD是个挑战　
　1.2　谁是目标读者　
　1.2.1　TDD和OOP　
　1.2.2　应用程序和数据库　
　1.3　什么是障碍　
　1.3.1　数据库就是对象　
　1.3.2　TDD适用于类，不适用于对象　
　1.3.3　我们需要数据库的类　
　1.4　小结　
第2章　建立数据库的类　
　2.1　TDD中类的角色　
　2.1.1　可靠的实例化过程　
　2.1.2　测试检查对象　
　2.2　面向对象编程语言中的类　
　2.2.1　类的构建很容易：构建新对象即可　
　2.2.2　一条途径：必要时析构　
　2.3　数据库的类　
　2.3.1　两条途径：创建或改变　
　2.3.2　难点：统一两条途径　
　2.3.3　真实的数据库的生长情况　
　2.3.4　将每个数据库构建成生产数据库会怎么样　
　2.3.5　所有数据库都遵循完全相同的途径　
　2.4　增量构建　
　2.4.1　用文档记录每一次数据库的变更　
　2.4.2　标识当前版本　
　2.4.3　根据需要依次实施变更　
　2.5　实现　
　2.5.1　需求　
　2.5.2　数据库实例化机制的伪代码　
　2.5.3　输入的伪代码　
　2.6　小结　
第3章　讲一点TDD　
　3.1　测试先行的技术　
　3.1.1　编写测试代码　
　3.1.2　让测试失败得有一些有价值的启示　
　3.1.3　看到测试运行通过　
　3.1.4　重复　
　3.2　测试即规格　
　3.2.1　“测试不是测试，而是规格”　
　3.2.2　“测试不是规格，而是测试”　
　3.2.3　测试是可运行的规格　
　3.2.4　增量设计　
　3.3　构建良好的规格　
　3.3.1　规定行为，而不是结构　
　3.3.2　从一无所有开始驱动设计，而不是从其他方式开始　
　3.3.3　从内向外地定义设计　
　3.3.4　从外向内地定义设计　
　3.4　小结　
第4章　安全地改变设计　
　4.1　什么是安全　
　4.1.1　违约有点糟　
　4.1.2　丢失数据可能会让你被炒鱿鱼　
　4.1.3　不改设计也同样危险　
　4.2　解决方案：过渡测试　
　4.2.1　测试驱动的实例化　
　4.2.2　建立过渡测试　
　4.2.3　累加变化的过渡测试　
　4.2.4　过渡测试的变形　
　4.2.5　为什么不使用公共接口　
　4.3　过渡保障　
　4.3.1　Read/Read过渡测试　
　4.3.2　每次升级时通过数据库的类来运行　
　4.3.3　备份和失败时回滚　
　4.3.4　让过渡测试充分利用过渡保障　
　4.4　小结　
第5章　遵循接口　
　5.1　接口的优势　
　5.1.1　更强的耦合语言　
　5.1.2　弱耦合的语言　
　5.1.3　共识　
　5.1.4　耦合到数据库的类　
　5.1.5　问题是发生了重复　
　5.2　像客户对象般的遵循　
　5.2.1　创建DatabaseDesign类的需求　
　5.2.2　规定DatabaseDesign类　
　5.2.3　摆脱使用多个客户端平台时出现的重复　
　5.2.4　当耦合出问题时会发生什么　
　5.2.5　消除数据库构建和客户端代码之间的重复　
　5.2.6　解除实现与设计之间的耦合　
　5.3　症结：变更　
　5.3.1　随时间而变化的设计　
　5.3.2　记录所有版本的设计　
　5.3.3　耦合到设计的正确版本　
　5.4　症结：耦合　
　5.4.1　不同的客户端耦合到不同的版本　
　5.4.2　总是不得不修改所有东西也是重复　
　5.4.3　透镜概念介绍　
　5.4.4　虚拟透镜　
　5.4.5　“当前”透镜　
　5.4.6　“新”透镜　
　5.5　小结　
第6章　定义行为　
　6.1　一组新问题　
　6.1.1　无封装　
　6.1.2　隐藏一切　
　6.1.3　数据库中的业务逻辑　
　6.2　知识、信息与行为　
　6.2.1　通告　
　6.2.2　知识　
　6.2.3　行为　
　6.3　由外而内地开发　
　6.3.1　定义测试　
　6.3.2　生长出接口　
　6.3.3　生长出行为和结构　
　6.4　用规格来实现合理的设计　
　6.4.1　开发当下的需求，而不是将来的需求　
　6.4.2　用增量的方式构建　
　6.4.3　将访问限定在规定的内容上　
　6.4.4　小结　
第7章　为可维护性而构建　
　7.1　再也不要担心未来　
　7.1.1　在当下寻找机会　
　7.1.2　针对通告进行设计　
　7.1.3　使用行为来翻译通告和知识　
　7.2　用激情和热忱来保护知识　
　7.2.1　不做改变是最危险的选择　
　7.2.2　让设计保持自然　
　7.3　当事情在未来发生时再处理　
　7.3.1　定义新的设计　
　7.3.2　引入最小的变化　
　7.3.3　让测试运行通过　
　7.3.4　停下来，思考，重构　
　7.3.5　小结　
第8章　错误与修复　
　8.1　各种错误　
　8.1.1　轴：好的错误还是坏的错误　
　8.1.2　轴：错误发布了没有　
　8.2　处理好的错误　
　8.2.1　修复它就好了　
　8.2.2　现在就记录行为　
　8.2.3　回溯功能的根源　
　8.3　处理坏的错误　
　8.3.1　未发布的错误　
　8.3.2　已发布的错误　
　8.3.3　灾难性的错误　
　8.4　小结　
第9章　设计　
　9.1　结构与设计　
　9.1.1　结构：执行细节　
　9.1.2　测试和类信息　
　9.2　什么是设计　
　9.2.1　概念之桶　
　9.2.2　真正的TDD中强制性的部分　
　9.3　组合与聚合　
　9.3.1　组合：一件事有多个组成部分　
　9.3.2　聚合：连接截然不同的东西　
　9.4　复用　
　9.4.1　避免将同样的内容开发两遍　
　9.4.2　通过组合或聚合来实现复用　
　9.5　抽象　
　9.5.1　发现运用抽象的机会　
　9.5.2　封装行为　
　9.5.3　寻找各种方式来允许变化发生在依赖关系中　
　9.5.4　处理时间问题　
　9.6　小结　
第10章　mocking　
　10.1　测试单个的行为　
　10.1.1　为什么封装　
　10.1.2　测试就是对那些在其控制之外的一切进行测试　
　10.1.3　从测试那里来控制不相关的行为　
　10.1.4　mocking控制了行为　
　10.2　在面向对象编程中的mocking　
　10.2.1　设置　
　10.2.2　解耦　
　10.2.3　隔离　
　10.2.4　集成　
　10.3　在数据库设计中使用mocking　
　10.3.1　示例问题　
　10.3.2　示例解决方案　
　10.3.3　组合　
　10.3.4　聚合　
　10.3.5　为可测试性而设计　
　10.4　小结　
第11章　重构　
　11.1　什么是重构　
　11.1.1　改变设计但不改变行为　
　11.1.2　在测试运行通过的背景下　
　11.2　较低和较高风险的设计变更　
　11.2.1　较低风险：改变类一级的设计　
　11.2.2　中等风险：重新安排行为的逻辑　
　11.2.3　较高风险：改变知识的容器　
　11.2.4　这不是一个跳过测试的邀请　
　11.3　小结　
第12章　遗留数据库　
　12.1　提升到一个类　
　12.1.1　推导初始版本　
　12.1.2　用测试来钉牢过渡行为　
　12.2　控制耦合　
　12.2.1　识别和锁定现有的使用数据库的情况　
　12.2.2　按需封装　
　12.3　控制变更　
　12.3.1　用测试驱动新的行为　
　12.3.2　按需钉牢构造行为　
　12.3.3　按需钉牢行为　
　12.3.4　实现新的行为　
　12.4　查找接缝和组件　
　12.4.1　查找接缝　
　12.4.2　封装组件　
　12.5　小结　
第13章　Fa?ade模式　
　13.1　使用Fa?ade的封装　
　13.1.1　Fa?ade模式的说明　
　13.1.2　测试驱动开发出来的新的Fa?ade数据库　
　13.1.3　使用组合方法的替代方案　
　13.1.4　封装还是不封装　
　13.2　扼杀旧接口　
　13.2.1　将正在改变的行为转移到Fa?ade　
　13.2.2　当不再需要时删除访问权限和功能　
　13.3　在Fa?ade数据库中对行为进行测试驱动开发　
　13.3.1　暴露遗留的行为