验收测试驱动开发

第一部分　机场停车场

第1章　停车费计算器讨论会

1.1　代客泊车

1.2　临时停车

1.3　经济停车和长期停车

1.4　基本实例

1.5　总结

第2章　代客泊车的测试自动化

2.1　第一个测试用例

2.2　结对完成第一个测试

2.2.1　初始化

2.2.2　检查结果

2.3　表格化测试

2.4　总结

第3章　其余的停车场实例的自动化

3.1　临时停车

3.2　经济停车

3.3　总结

第4章　期望与协作

4.1　需求讨论会

4.2　主观期望的思维方式

4.3　协作

4.4　总结

第二部分　交通信号灯软件系统

第5章　开始

5.1　交通信号灯

5.2　FitNesse

5.3　支持代码

5.4　总结

第6章　信号灯状态

6.1　状态需求

6.2　第一个测试

6.3　深入代码

6.4　重构

6.4.1　包

6.4.2　LightState枚举

6.4.3　编辑LightState

6.5　总结

第7章　第一个路口

7.1　控制器的需求

7.2　驱动控制器的实现

7.3　总结

第8章　发现和探索

8.1　发现领域

8.2　驱动产品代码

8.3　测试你的粘合代码

8.4　粘合代码的价值

8.5　总结

第三部分　验收测试驱动开发的原则

第9章　使用实例

9.1　使用合适的格式

9.1.1　行为驱动开发

9.1.2　表格格式

9.1.3　关键字驱动的自动化

9.1.4　粘合代码和支持代码

9.1.5　正确的格式

9.2　细化实例

9.2.1　领域测试

9.2.2　边界值

9.2.3　配对测试

9.3　裁减实例

9.4　考虑缺失

9.5　总结

第10章　协作确定需求

10.1　见识“三的力量”

10.2　举办讨论会

10.2.1　参加者

10.2.2　讨论会的目标

10.2.3　频率与时长

10.3　捕捉需求

10.4　总结

第11章　基于文本的自动化

11.1　使用友好的自动化

11.2　自动化上的协作

11.3　发现领域

11.4　总结

第12章　整洁的测试

12.1　测试自动化的开发

12.2　倾听测试的声音

12.3　重构测试

12.3.1　提取变量

12.3.2　提取关键字

12.4　总结

第13章　成功运用ATDD

附录A　Cucumber

A.1　特性文件

A.2　步骤定义

A.3　产品代码

附录B　FitNesse

B.1　Wiki结构

B.2　SLiM表格

B.3　支持代码

附录C　Robot Framework

C.1　段落

C.2　库代码

使用验收测试驱动开发（ATDD），业务人员、测试人员和开发人员可以协作产出可测试的需求，帮助团队更快速地构建高质量软件。然而，许多实践者仍然对ATDD存在误解。“ATDD by Example”是第一本成功实施和运用ATDD的入门级实践操作指南。
　　ATDD先锋Markus G?rtner将手把手教授读者如何从业务人员那里派生出正确的软件系统，同时实现能准确反映业务需求并有助于提升开发效率的全自动化功能测试。
　　通过两个端到端案例的研究，Gartner演示了如何使用不同的框架和语言来实施ATDD。每一个案例都涉及了大量的实际产出，包括测试自动化类、步骤定义和完整的案例实现。这些实例形象地说明了ATDD的基本原则，展示了ATDD是怎样融入开发流程的，给出了来自G?rtner广泛经验的重要提示，也指出了要避免哪些危险的陷阱。
　　读者会学到以下内容：
　　- 掌握成功实施ATDD的思维过程；
　　- 通过Cucumber使用ATDD来描述能够使得业务人员理解的软件；
　　- 使用ATDD工具测试网页；
　　- 通过基于wiki的验收测试框架的FitNesse，把ATDD带到Java中；
　　- 通过全新的讨论会形式来协作地产出软件需求；
　　- 实现更加用户友好的、协作的自动化测试；
　　- 更整洁地测试，聆听测试结果，并以价值驱动测试重构。
　　如果你是一个测试人员、分析师、程序员或项目经理，这本书能保证你马上从ATDD中获取真实的收益——而且随着你实际经验的不断增加，你会得到更多价值。

Kent Beck序
　　本书介绍验收测试驱动开发（Acceptance Test-Driven Development，ATDD）的方式，与使用ATDD开发软件的过程，有着奇妙的对应关系。通过选择特定的程序行为实例引出系统的正确行为是一门艺术，通过挑选特定的编程实例让读者更好地学习某种编程技术（如ATDD）也是一门艺术。Markus选取和呈现实例方面的能力的确令人钦佩。
　　要阅读本书，你就需要阅读代码。如果你跟得上，你就有机会完成掌握ATDD所必需的思维转变。这种转变简单来说，就是很快从“这是我需要的一个特性”转变为“我们如何去测试它呢？这是个例子。”阅读这些例子，你就会反复在不同的上下文环境中看到这种转变具体是什么样子。
　　我之所以喜欢这种以代码为中心的表述方式，是因为我充分信任读者的学习能力。这不是那种印在薄薄的技术宣传包装纸上的“测试Web应用的12个简单原则”，一放到残酷的现实中就会大打折扣。在这里你能看到在具体上下文中所做的具体决定。这些决定你可能会（如果你想从书中获得最大的收获，你一定会）不同意，争辨，并作出自己的决定。
　　本书的后半部分给出了一些普遍的结论，总结了在工作中使用“实例”的一些原则。如果你是那种熟悉了普遍概念之后学东西会更有效率的人，那么从那里开始阅读是个不错的主意。但是，你能从本书学到多少，直接取决于你愿意花多少精力研究那些实例。
　　就像我曾说过的，TDD（测试驱动开发）的一个弱点是，它可能会退化为一种用来满足开发人员需求的编程技能。某些开发人员从更宽泛的角度来看待TDD，轻易在他们测试的不同抽象级别间跳跃。然而在ATDD中不存在歧义，这是一种加强与非编程人员沟通的技术。我们之间良好的协作关系，以及作为这种关系基础的沟通，能够使软件开发更有效率。采用ATDD是向着沟通更清晰这个目标迈进的重要一步，而此书是一本全面又平易近人的入门读物。