《验收测试驱动开发：ATDD实例详解》目录—导读

版权声明
验收测试驱动开发：ATDD实例详解
Authorized translation from the English language edition, entitled: ATDD by Example: A Practical Guide to Acceptance Test-Driven Development, 9780321784155 by Markus Gtner, published by Pearson Education, Inc., publishing as Addison-Wesley Professional, Copyright 2013 Pearson Education, Inc.

All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Pearson Education, Inc.

CHINESE SIMPLIFIED language edition published by PEARSON EDUCATION ASIA LTD. and Posts & Telecommunications Press Copyright 2013.

本书中文简体字版由Pearson Education Asia Ltd. 授权人民邮电出版 独家出版。未经出版者书面许可，不得以任何方式复制或抄袭本书内容。

本书封面贴有Pearson Education（培生教育出版集团）激光防伪标签，无标签者不得销售。

版权所有，侵权必究。

献给我的妻子Jennifer、我的宠物Leon和我的女儿Katrin，

感谢你们允许我用本来应该是陪伴你们的时间来完成此书。

Dale Emery序
验收测试驱动开发：ATDD实例详解
最终没能向客户交付符合要求的软件的项目太多了。多年来，我听到不少项目的客户这样解释失败的原因：开发人员根本不重视我们到底要什么。同时，我听过上百个程序员这样解释：客户根本不告诉我们他们到底要的是什么，大部分时间甚至他们自己都不知道自己要的是什么。

我研究了足够多的项目得出一个不同的结论：描述一个软件系统的职责是很困难的。这需要人们讲述和倾听的精确度都远远超过平常交流的程度。编写好的软件是很难的，做好软件测试也是很难的，但软件业中最难的工作是清晰地表达我们希望系统做什么。

验收测试驱动开发能帮助我们应对这个挑战。采用ATDD使整个团队在开发开始前就相互协作，以获得对系统清晰一致的理解。ATDD有两个核心实践：首先，在实现任何特性前，团队成员相互协作构造出当前特性的一个具体实例；其次，团队将这个实例翻译成自动化的测试用例。这些实例及其测试作为重要的组成部分，一致而精确地定义了每个特性“完成”的标准。

取得一致的理解到底有什么用个开发者在ATDD研讨会上是这样解释的：“一旦我们开始一起创建实例，我就真正开始关心我们正在做的事情了。最终我理解了我们要做什么以及为什么要这么做。更重要的是，我知道整个团队都明白我们的目标。于是，我们拥有了共同的目标，我们成为了一个真正的团队。”

ATDD不仅帮我们了解何时才算做完，还能告诉我们进度如何。因为我们对每一个测试进行了自动化，并且编写程序通过一个个测试（和以前的所有测试），那些实例就像是路边的路标，引导我们到达最终的目标。同时，由于每一个实例都代表了一个对用户有价值的功能，所以我们相信自己不仅是取得了进展，而且这些进展都是有价值的。

好了，我已经列举了ATDD的核心要点和一些主要的好处。这不难，难的是在现实世界中究竟如何做才能成功个问题的解答就留给Markus Gtner了。在本书中，Markus不仅仅向你讲述，更向你展示了ATDD在实践中是如何运用的。他让你看到测试人员、开发人员以及业务专家在运用这些ATDD原则和实践时到底是怎么想的。

这里我要告诫本书读者，在最初的几章里，我们将跟随业务专家Bill、测试人员Tony、开发人员Phyllis和Alex一起来描述和实现一个小的软件系统。这个系统初看上去可能有些简单，或者过于简单化了，但是不要被表象所迷惑，其实这几章涵盖了很多内容。这是一个高素质的团队，他们拥有的某些技能十分精巧。举例来说，你应该注意到，在需求讨论会上，团队成员没有提及任何技术细节。他们完全关注于系统的业务职责。同样需要注意的是，在Alex和Tony对最初几个测试进行自动化时，Tony充分利用了他“缺乏”编程经验的特点。任何时候，当他对技术细节感到困惑时，他都会要求Alex向他解释，然后和Alex一起修改代码，直到使它们变得清晰明了。还要注意，Alex经常强调要将测试代码提交到源代码管理系统中——但只在这些测试能运行之后。如果你刚接触ATDD，那么这些技巧可能不那么明显，但它们对于成功运用ATDD是至关重要的。

幸运的是，只要你能继续读下去，你就能学到这些精巧的技能。Markus经常会停下来解释团队正在做什么，以及为什么这么做。在每章的末尾他都会总结团队是如何协同工作的，并且在本书结尾，Markus会做一个总结，详细描述成功运用ATDD需要遵循的原则。

本书是验收测试驱动开发的绝妙介绍。即使像我这样实践ATDD有一段时间的人，也能在本书中发现全新的视角。最后，这是一本值得反复阅读的书。阅读，实践，再阅读。每次阅读你都能学到一些有用的新东西。

Kent Beck序
验收测试驱动开发：ATDD实例详解
本书介绍验收测试驱动开发（Acceptance Test-Driven Development，ATDD）的方式，与使用ATDD开发软件的过程，有着奇妙的对应关系。通过选择特定的程序行为实例引出系统的正确行为是一门艺术，通过挑选特定的编程实例让读者更好地学习某种编程技术（如ATDD）也是一门艺术。Markus选取和呈现实例方面的能力的确令人钦佩。

要阅读本书，你就需要阅读代码。如果你跟得上，你就有机会完成掌握ATDD所必需的思维转变。这种转变简单来说，就是很快从“这是我需要的一个特性”转变为“我们如何去测试它呢是个例子。”阅读这些例子，你就会反复在不同的上下文环境中看到这种转变具体是什么样子。

我之所以喜欢这种以代码为中心的表述方式，是因为我充分信任读者的学习能力。这不是那种印在薄薄的技术宣传包装纸上的“测试Web应用的12个简单原则”，一放到残酷的现实中就会大打折扣。在这里你能看到在具体上下文中所做的具体决定。这些决定你可能会（如果你想从书中获得最大的收获，你一定会）不同意，争辨，并作出自己的决定。

本书的后半部分给出了一些普遍的结论，总结了在工作中使用“实例”的一些原则。如果你是那种熟悉了普遍概念之后学东西会更有效率的人，那么从那里开始阅读是个不错的主意。但是，你能从本书学到多少，直接取决于你愿意花多少精力研究那些实例。

就像我曾说过的，TDD（测试驱动开发）的一个弱点是，它可能会退化为一种用来满足开发人员需求的编程技能。某些开发人员从更宽泛的角度来看待TDD，轻易在他们测试的不同抽象级别间跳跃。然而在ATDD中不存在歧义，这是一种加强与非编程人员沟通的技术。我们之间良好的协作关系，以及作为这种关系基础的沟通，能够使软件开发更有效率。采用ATDD是向着沟通更清晰这个目标迈进的重要一步，而此书是一本全面又平易近人的入门读物。

译者序
验收测试驱动开发：ATDD实例详解
随着敏捷软件开发方法在国内越发普及，验收测试驱动开发（ATDD）作为其中重要的一个实践，也越来越多地受到人们的重视。尽管常常听到这个名词，但相比于Scrum、持续集成等一些敏捷实践，ATDD在很多人的脑海中还都是一个比较模糊的概念。虽然在 络上经常可以看到有关ATDD的文章，但系统地介绍ATDD的书籍则是少之又少。

ATDD究竟是什么和TDD（测试驱动开发）、BDD（行为驱动开发）、Specifi- cation by Example（实例化需求）到底是什么关系多人都心存疑惑。看完本书后，你应该就能得到属于自己的答案了。

本书深入浅出地介绍了ATDD。不论是对敏捷开发的爱好者，还是打算采用ATDD方法的敏捷团队都有很高的参考价值。对于国内处于起步阶段的敏捷团队，更是不可多得的工作指导。当然，任何团队、任何项目都是独一无二的，没有一个“标准模式”是在任何情况下都适用的。我们需要根据团队和项目的特点去创造属于自己的方法，而不是全盘照搬“标准模式”。这一点对于应用ATDD也不例外。Markus在书中不断告诫我们：在实践中，每个团队都需要找到适合自己的ATDD应用方式，通过应用一些简单的ATDD实践，总结经验，不断调整，才能找到适合自己的方式。虽然不存在所谓的“标准模式”，但书中对如何创造属于自己的ATDD方法指明了方向。

这次能有机会将这样一本好书介绍给国内读者，我们十分荣幸。在此特别要感谢乔梁的校阅，他在技术书籍翻译方面的深厚功底让我们受益匪浅；也谢谢以下同事和朋友在翻译过程中给我们的宝贵意见：林雪清（诺西）、齐贺（百度）、杨景希（百度）和啜悦；最后，此书的完成也离不开百度敏捷教练组领导和同事们的支持。

张绍鹏　冯上

2013年2月于北京

致谢
验收测试驱动开发：ATDD实例详解
一个项目，就像写这本书，如果没有那么多人的支持和帮助是不可能成功的。首先，我要感谢Dale Emery，他对我的写作风格提供了很好的建议。作为一个母语非英语的作家，我非常感谢Dale给我的反馈。

特别要感谢Kent Beck。2010年8月，我跟他探讨了用他写作Test-Driven Developmet：by Example的方式写一部关于ATDD的书。他还将我介绍给Addison-Wesley的Christo pher Guzikowski，后者为我出版本书提供了全面的支持。

一些人对我早期的书稿提供了反馈意见。在这里我要感谢Lisa Crispin、Matt Heusser、Elisabeth Hendrickson、Brett Schuchert、Gijko Adzic、George Dinwiddie、Kevin Bodie、Olaf Lewitz、Manuel Kublbock、Andreas Havenstein、Sebastian Sanitz、Meike Mertsch、Gregor Gramlick还有Stephan Kamper。

最后同样重要的是，我要感谢我的妻子Jennifer以及我们的孩子Katrin和Leon，他们支持我写完了这本书。我希望在未来几年能够补偿他们这段缺乏丈夫和父亲陪伴的时光。

前言
验收测试驱动开发：ATDD实例详解
在这本书中，我会对现在被称为验收测试驱动开发（ATDD）的实践做一个入门级的介绍。当我在2008年第一次接触ATDD这个词时，我认为它有点儿做作，没什么必要。当时我已经学会了测试驱动开发而且发现这已经足够了，ATDD对我来说有点儿多余。究竟为什么我需要为验收标准做测试呢/p>

“时间能改变一切”[Wei86]。所以四年后我发现自己正在写一本关于验收测试驱动开发的书。2009年，我遇到了Gojko Adzic，他刚完成自己的著作Bridging the Communication Gap，他给了我一本，在回伦敦的路上我立刻读了起来。当我读完之后，我对什么是ATDD有了更好的理解，并且明白了为什么我们要避免使用这个词。

但是为什么我还是用ATDD by Example命名你手中的这摞纸呢

关于命名
ATDD这个概念存在一段时间了。它有许多不同的名字，下面是一个不完整的清单：

验收测试驱动开发（Acceptance Test-Driven Development）；
行为驱动开发（Behavior-Driven Development，BDD）；
实例化需求（Specification by Example）；
敏捷验收测试（Agile Acceptance Testing）；
用户故事测试（Story Testing）。
在我看来，这些名字都存在缺陷。验收测试驱动开发会给人这样一种印象：验收测试通过了，我们的迭代就完成了。这是不正确的，对任何一组选定的测试，覆盖率都不是百分之百的。测试保护 也会有漏洞。测试不可能覆盖所有的情况，这在测试领域是众所周知的。不过就像Michael Bolton说的，至少当验收测试没有成功时，我们必然能知道工作还没有完成。

虽然对这些名字做了一些讨论，我还是决定将可能的候选名称都列在这里，并让读者根据自己的需要选择。最终我并不关心你怎么称呼它，只要它对你是有用的。软件开发的世界里，充满了有误导性的词汇，并且这种情况很可能还会持续很多年。软件工程、测试自动化、测试驱动开发全都会在某些方面引起误解。正如任何抽象概念一样，不要混淆了它的名字跟它真实的内涵。专家会知道这种方法的名字的局限性。

但为什么同一个方法会有这么多不同的名字呢且采用的实践可能也很不同。通过咨询和访谈多个公司使用ATDD的多个团队，我发现他们有一个共同点：每个团队都跟别的团队不同。同一种实践对你现在所在的公司的团队是有效的，很可能在另一个环境中会带来灾难性后果。你是否会奇怪咨询师的回答常常是“这要看情况”就是原因所在。

为了写作Specification by Example[Adz11]，Goiko Adzic采访了不同公司中的50多个使用ATDD的团队。他发现ATDD方法伴随着多种多样的实践。所有成功应用ATDD的团队都开始于一些最基本的实践，过一段时间再回顾一下，然后根据他们自己的实际情况做一些改变。从一个轻量级的过程开始，并且在发现有问题的时候引入一些新的东西，对于实践任何方法都是一种十分敏捷的方式。当你尝试ATDD的时候，要记住：最初采用的那些实践可能无法解决你所有的问题。过些时候，当你有了更多的经验，你就可以定制自己的解决方案了。

为什么要写另一本关于ATDD的书
虽然Gojko描述了很多成功运用ATDD的模式，我发现目前关于ATDD的书籍还有一些缺失。一种技巧或方法的高级使用者和入门级使用者的需求是有显著区别的。

在浏览关于ATDD的文献时，我发现有几本书在较高层次解释了ATDD，提出了一些原则。对高层次的学习者来说，在他们特定的环境下应用原则是非常简单的。但是对于新手来说，并不是这么回事。一个新手需要更具体的指引才能上路。一旦他有了基本的经验，他就可以去打破方法中硬性的约束了。

按图索骥是新手最好的学习方式，但本书并不是一本ATDD攻略。通过本书中的例子，我提出了两种ATDD的应用方式，并展示了其中参与者的思维过程。新手可以根据这些内容在自己的团队中开始尝试ATDD。在后面的部分，我提供了一些更深层次的学习资料。

本书最基本的想法来自于Kent Beck的《测试驱动开发》（Test-Driven Development：By Example）。Beck提供了两个测试驱动开发的真实例子，最后解释了背后的一些原则。它的目标就是成为一个入门级的TDD介绍，提供充足的学习资料供新手去学习——认为通过反思和实践，就可以掌握TDD。从某些角度来说，本书也是这样的。

术语表
本书中我会用到一些敏捷软件开发中的术语。考虑到并不是人人都了解敏捷软件开发，这里只提供一个术语的简单解释。

产品负责人（product owner）。敏捷方法Scrum定义了3种角色：开发团队、Scrum Master和产品负责人。产品负责人对团队所开发的产品是否成功负责。他需要为团队要实现的特性确定优先级，并且和其他利益相关人一起工作来获取上述特性。对于团队来说，他还是客户代表，负责决定功能的细节。他通过与其他利益相关人协商来确定这些细节。
迭代或Sprint。敏捷开发基于一种称为迭代的固定开发周期，在Scrum中称作Sprint。在这些短周期内，团队需要实现一个潜在可发布的增量产品。通常的迭代长度是1～4周。
用户故事（user story）。用户故事是让团队感到在一个迭代中能轻松完成的有限的功能集。这是一些很小的功能片段。通常团队会尽力在一个迭代中完成多个用户故事。业务代表或产品负责人负责定义这些故事。
任务看板（taskboard）。大多数敏捷团队在一个所有人都可见的白板上规划他们的工作。他们使用卡片说明当前正在进行的工作。任务看板通常有多个列，至少包括ToDo（待办）、Doing（进行中）和Done（完成）。随着项目的进展，团队通过更新看板来反映进度。
故事卡（story card）。用户故事通常写在真实的卡片上，在迭代中，卡片会被贴在任务看板上。
站立会议，每日Scrum会议。**团队成员每天至少更新一次他们在迭代中的进度。团队花15分钟在一起讨论如何完成迭代中剩余的任务。
产品需求列表（product backlog），Sprint任务列表（sprint backlog）。Scrum中的产品负责人在产品需求列表中记录所有的未完成的故事。一旦有新的需求，他会负责更新这个列表。当团队一起为下一次迭代做计划时，团队成员会为下一次迭代确定一个任务列表。这就是Sprint任务列表。从产品需求列表中选出的故事自然成为Sprint任务列表的一部分。Sprint任务列表通常在计划会议结束后被记录在任务看板上。
重构（refactoring）。重构是在保持功能不变的基础上，改变原代码的结构。通常我会在修改代码前重构代码。通过重构代码，可以使将来修改代码变得更容易。
测试驱动开发（TDD）。采用测试驱动开发，你首先需要写一个失败的测试，写足以使这个测试通过的代码即可（同时保证其他之前通过的测试依然通过），然后重构你的代码，为下一步做准备。TDD是一种设计方法，它帮助使用者编写更好的代码，因为这些代码默认就是可测试的。
持续集成（continuous integration，CI）。在持续集成中，你频繁集成改动的代码。一个构建服务器将构建整个分支，运行所有的单元测试和全部的验收测试，并且将此次构建的结果通知你的同事们。持续集成依赖于自动构建，如果当前分支的状态出现问题，它能帮助团队在第一时间发现，而不是在产品发布前一小时才发现。
如何阅读本书
本书在提供具体实践的同时，还提出了一些有用的原则。阅读本书可以用多种方式，根据自己的经验水平，你可以挑选任何一种。

你可以一页页地顺序阅读本书，你会更多地了解Cucumber、行为驱动开发以及如何用ATDD工具测试 页。在第一部分中，第一个案例基于一个区分开发专家和测试专家的团队。在这里你会发现相互协作是最重要的成功因素。

在第二部分中，我会与你结对。通过结对，我们可以弥补任何缺失的测试或开发知识。我们会用一种很实际的方式利用ATDD来驱动我们的应用开发。我们会用到FitNesse，一个基于wiki的验收测试框架。第二部分的实例是用Java语言编写的。

在第三部分中，你会发现应用这种方法的一些入门的指导。我也会给出进阶读物的指引，并给出一些关于其他团队如何开始，什么对他们有效，以及什么对他们无效的经验。

你可以在附录中找到书中用到的两种工具和另外一种工具更详细的使用说明。如果你没有接触过Cucumber或FitNesse，你可能希望从这里开始看起。

高阶读者可以跳过前两部分，直接从第三部分我总结的原则看起。如果你希望稍后向你的同事提供一些背景知识，你可以参考第一部分和第二部分的内容。

你也可以先读前两个实例，然后回过头在你的工作中开始尝试应用它。当你遇到无法解决的问题时，再阅读第三部分中更多的内容。不过，我并不推荐以这种顺序阅读本书。

如果你已经在你的团队中开始了ATDD的尝试，也许你愿意更深入地研究一下第二部分。在那里，我解释了如何由实例驱动出领域代码。

这些是我能想到的一些阅读本书的方式。如果你喜欢我，或许你会想跟随案例自己编写一下书中的代码。我为所有的实例代码准备了一个GitHub代码仓库（repository）。这样我可以验收测试我自己的示例代码。如果你发现自己有什么问题，你也可以以这个作为参考。你可以在http://github.com/mgaertne/airport找到第一部分的代码，第二部分的源代码在http://github.com/mgaertne/trafficlights。

1或者，为什么我要用特别的0/1排列，使它在你的电子设备上显示为“ATDD by Example”呢/p>

目录
前言
第一部分 机场停车场
第1章　停车费计算器讨论会
1.1　代客泊车
1.2　临时停车
1.3经济停车和长期停车
1.4　基本实例
1.5　总结
第2章　代客泊车的测试自动化
2.1　第一个测试用例
2.2　结对完成第一个测试
2.3　表格化测试
2.4　总结
第3章　其余的停车场实例的自动化
第4章　期望与协作
第二部分　交通信 灯软件系统
第5章　开始
第6章　信 灯状态
第7章　第一个路口
第8章　发现和探索
第三部分　验收测试驱动开发的原则
第9章　使用实例
第10章　协作确定需求
第11章　基于文本的自动化
第12章　整洁的测试
第13章　成功运用ATDD
附录A　Cucumber
附录B　FitNesse
附录C　Robot Framework

文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览91308 人正在系统学习中 相关资源：专业LED灯光动画制作软件(安装后直接用!)_setup安装包-Delphi工具…