采访与书评 —— 《BDD In Action》

由 John Ferguson Smart 所编写的《BDD In Action: Behavior-Driven Development for the Whole Software Lifecycle》一书旨在完整地涵盖BDD 实践的方方面面，从需求分析到生产环境中的代码开发，通过可执行规范与自动化测试支撑着整个流程。因此本书可分为四个部分：BDD 的介绍、需求分析技术、BDD 技术以及对BDD 的更广泛应用。

BDD 这一术语（及实践）经常被人们误解，因此本书借此机会对 BDD 进行了定义（以及它和 TDD、ATDD 以及实例化需求有何不同之处），并概述了它的优缺点以及核心原则。

行为驱动开发（BDD）是一系列软件工程实践，它的设计目的是帮助团队更快地开发及交付更有价值的、质量更高的软件。它……提出了一种基于简单的结构化语句的通用语言……能够在项目团队成员与业务干系人之间建立起良好的沟通。

BDD 首先专注于能够交付业务价值（或者称为能力）的特性，因而本书的下一部分自然地涵盖了使用 BDD 进行需求定义，以及为确保你创建了正确的功能所必需回答的重要问题。这一部分对于特性注入（Feature Injection）、影响地图（Impact Mapping）、基于目的的对准模型（Purpose-Based Alignment Model）、实质选择权（Real Options）和刻意发现（Deliberate Discovery）等技术进行了全面的叙述。

用户通过使用我们的软件得到的能力能够帮助他们实现业务目标，而特性则是我们为支持这种能力而为用户所交付的东西。特性是一种有形的功能，它能够体现出对用户的价值……特性或许能够在一次或多次迭代中进行交付……特性是以业务术语和一种能够被管理者所理解的语言所表述的。

本书的下一部分讲述了如何将特性分解为可管理的块（用户故事），以达到计划的目的，并且通过具体的实例确保对特性的理解以及对不确定性的澄清。

BDD 实践者将具体的实例表述为可执行的场景，它使用一种半结构化的格式“given……when……then”，这种格式对于干系人与团队成员来说都很容易阅读。

在需求定义这一部分中，有很大一部分篇幅用于描述如何编写可执行的场景的提示与示例，其中使用了 Gherkin 与 JBehave 这两种语言格式，并且描述了如何通过特性文件和标签对它们进行组织，最后说明如何使它们实现自动化。

Scenario 描述了高层次的需求……Step 定义则对 Scenario 文本进行解释，并通过调用自动化测试层以运行实际的任务……自动化测试层与待测试的应用进行交互……对于编写可维护的、可读的自动化验收测试来说，这种分层架构是关键所在。

从本书的第三部分开始，关注点就从需求转换到代码和自动化测试等技术方面的内容，并且对于代码设计、单元测试、自动化测试测试、UI 测试以及对非功能性需求的测试提供了大量的技术参考。这部分内容同样提供了以不同语言编写的大量示例，包括 C#、Java、JavaScript 和 Python，使用的工具包括了 Selenium WebDriver、SpecFlow 和 Thucydides。

在编写自动化验收场景时，通过使用分层技术，能够将高层次的、更稳定的业务规则从更易变的、低层次的测试实现细节中分离出来……业务规则层用一种高层次的业务术语描述了待测试的需求……而业务流层……展现了用户对系统进行使用，以实现一个特定的业务目标的整个过程……技术层在一个细节层面上展现了用户如何与系统进行交互，即他们如何导航至注册页面、在进入页面后会输入什么内容、如何在 HTML 页面中鉴定这些字段，等等。

本书的最后一部分涵盖了 BDD 流程所带来的一些产物，例如活文档（Living Documentation）和持续交付流程。

由自动化测试所生成的报告……它结合了原始的规范、验收场景以及测试结果，我们将其称为活文档……首先，同时也是最重要的一点，BDD 报告对于应用的期望行为进行了文档化及描述，并且在报告中表现出该应用是否正确地执行了这些操作。当你深入到其中的细节时，BDD 报告还从用户的角度阐述了某个特定的特性或功能是如何运行的。

总的来说，全书的结构非常平衡，它带领读者从特性开发的初始对话开始，一路走过需求、开发以及测试阶段。与有关这一主题的其它许多书籍不同的是，本书在涵盖了整个 BDD 生命周期的同时，也对技术与测试等方面进行了深入的讲述，而没有迷失在对某个特定的工具或语言的使用中。

本书应当会引起 BDD 角色中的“三友”（three amigo）的兴趣，三友是指开发者、测试人员和业务分析师 / 产品负责人，因为本书的可读性非常强，为具有良好平衡性的跨功能性敏捷团队提供了对 BDD 的洞察力。但这一点也可能成为本书的不足之处，它对于 BDD 进行了端到端的描述，这可能会吓跑非技术背景的读者，而对于具有技术能力的读者来说，或许又会感到对于某个特定的工具或语言缺乏深入的讲解。但无论如何，这本书非常出色地涵盖了 BDD 这一主题（以及许多相关技术）的方方面面，对于寻求对 BDD 的理解，或是寻找高效的实现途径的读者来说是一个很好的参考。

最近，InfoQ 有幸与作者 John Ferguson Smart 关于这本书进行了一次访谈。

InfoQ：祝贺你完成了这本书。目前市面上关于 BDD与相关主题的书籍已经很多，是什么原因促使你撰写了本书，你觉得它的独特之处在什么地方？

John：我感觉在 BDD 这一主题下还缺乏一本能够全方位涵盖其内容的书籍，从需求的发现，到对应用的编码、编写自动化验收测试、以及交付活文档。人们对于 BDD 的理解往往是非常有限的，因此我希望能够让用户更多地了解，BDD 实际上是非常广泛与全面的。Gojko Adzik 所撰写的《实例化需求》一书提供了许多优秀的学习案例，但自从那本书面世之后，又浮现出了许多新的实践与工具。此外还有许多关于 TDD 的书籍，但我感觉它们都没有抓住从需求发现到指出业务价值之间的流向，并且过于专注于技术层面，使用的技术栈也非常过时。对于 Java 开发者来说，其中的内容很少能够产生即时的实用性。

InfoQ：人们对于 BDD的定义一直感到很困惑，你对它的基本解释是怎样的？

John：我乐于将 BDD 定义为一种协作的方式，通过关于具体实例的对话，对怎样的特性才能够为组织交付价值创造一种共识。一旦良好地完成了这些对话，你就能够使用实例为这些特性定义清晰的、无歧义的验收场景了。如果你为这些验收场景实现了自动化，就能够以一种业务人员可以理解的语言获得快速且可靠的反馈，以了解具体实现了哪些特性。

这一原则可以应用在任何层次上。从更技术化的层面上，清晰的验收场景能够帮助我们理解要创建什么、不要创建什么，并且理解为什么这样选择。BDD 会促使你在编写实际代码前，为你将要编写的代码撰写可执行的技术规范。因而得到了经过良好测试的代码以及针对该代码的可靠的规范，它能够作为进一步开发的技术文档。因此，在这个意义上，BDD 单元测试工具，例如 Spock、RSpec 和 Jasmine 能够让我们更方便、更直觉式、并且更高效地实践测试驱动开发。

但 BDD 不是一种严格定义的实践集合，不存在什么“认证 BDD 实践者”的认证，也没有什么官方的团体能够定义是或不是标准的 BDD。举例来说，我曾与许多在地球上另一面的团队共同合作，帮助他们更清晰地表述他们的需求，因此这种协作并不一定是面对面的（至少我们就不是）。我还听说有些团队在非 IT 项目中也使用对话方式，以及编写 BDD 风格的场景，用于澄清对需求的理解，因此这一过程中不存在自动化的问题。

InfoQ**：你在本书中谈到了协作在 BDD中的重要性，尤其是在“三友”（开发者、测试人员以及客户 / 分析师）之间的协作。对于这些角色来说，要想在实施 BDD过程中取得成功，关键的区别有哪些？**

John：我想说的是，“三友中的‘三’其实表示的是从三到七之间的任何一个数字”。这些角色之间是相互弥补的，为了取得最好的结果，需要有一定创造性的张力。业务分析师（或产品负责人、或客户）的角色本质上代表了客户的需求，或者说已了解的客户需求，通过对具体实例进行对话了解客户如何使用这一应用并从中受益。而参与者中的其它角色将对这些实例提出质疑，他们会提出反例或是边缘情况，这往往是业务分析师甚至是整个业务团队没有考虑过的内容。开发者擅长于确保这些特性的技术可行性，也可能会建议使用一些替代方案，它能够实现相同的目标，而在技术方面更上一层楼。

InfoQ**：除了编写本书之外，你也在 BDD和自动化测试方面进行过大量的授课，并且组织过多次 dojo活动。在这些参与者中，你是否经常看到一些恍然大悟的情景？**

John：这些恍然大悟的情景中最令人激动的一点是他们理解了协作在整个过程中起到了多大的作用，人们总是将 BDD 当作一种自动化测试实践，或是一种使用大量的“Given……When……Then……”语法编写需求与验收场景的不同方式。但 BDD 真正的价值来自于共识，这种共识来自于讨论，正是它创造了这些验收场景。

InfoQ**：人们经常（错误地）将 BDD与敏捷工作方式联系在一起。那么通常来说，BDD为软件开发所带来的关键优点是什么呢？**

John：对于敏捷以及其它更规范的开发流程来说，许多 BDD 实践都是非常实用的。举例来说，以某种方式编写验收场景，使它能够转换为可执行的形式（或者说“可执行的规范”），这能够帮助我们确保验收场景是无歧义的、高质量的。不过，在对这些需求进行定义的过程中，如果在业务分析师与其它团队成员之间缺乏面对面的沟通，那么整个反馈流程以及审查流程的速度将会降低。

即便如此，敏捷流程对于团队的不确定性管理给出了更大的范围，并且与他们对需求，以及对所创建的解决方案的理解的不断改进相匹配。“三友”以及协作式地定义验收场景等实践对于消除需求中的不确定性是非常优秀的方式。

无论你使用何种开发流程，使用 BDD 实践编写代码（特别是为你的低层次 API 编写“可执行规范”）都是一种优秀的方式，它能够生成可靠的、经过良好测试的、并且经过文档化的代码，这些代码不仅质量过关，并且符合目标。

我曾经看到过多种 BDD 实践与工具，尤其是“活文档”这一思想能够有效地用于对遗留代码进行单元测试和验收测试的改进。无论是在单元测试层面或是验收测试层面，BDD 自动化测试都能够成为一种优秀的方式，它能够理解应用程序的作用并对其文档化，并且能够实现高效并且更具针对性的回归测试。

InfoQ：工具在本书中占据了很大的篇幅，包括考虑使用哪些工具，以及使用方式的某些提示。在你看来，如今的 BDD工具还存在着哪些方面的不足？

John：我认为，在敏捷项目管理与需求定义、验收测试自动化以及报表功能的集成方面还可以做得更流畅一些。

InfoQ：你是 Serenity BDD（之前被称为 Thucydides）的主要贡献者，是什么原因促使你编写了这个工具，它对于 BDD能够带来怎样的帮助？

John： Serenity 体现了我的一种理念，即需求及自动化测试应当融合在一起，生成实用的、可访问的活文档，而不仅仅是简单的测试报告。

它是基于 Cucumber 和 JBehave，或者说甚至是 Junit 等 BDD 工具进行构建的，能够帮助你编写更清晰的、可维护性更好的自动化验收测试以及回归测试。Serenity 试图在自动化测试中促成许多良好的习惯，例如对自动化代码进行分层式的抽象，以及自描述文档。

Serenity 也使得验收测试更易于与它所描述的需求相关联，我的想法是，在生成的报告中不仅仅能够告诉你哪些测试已经被执行，更重要的是告诉你哪些需求已经被测试过了。

InfoQ：编写一本书的过程通常是很漫长的。目前这本书已经问世，那么有什么主题是你希望能够加入到这本书中的吗？

John：我希望能够加入一些关于故事映射（Story Mapping）方面的内容，这是一种非常强大的需求发现技术，它能够与其它 BDD 实践进行很好的结合。

我也希望能够加入一个章节，描写如何用 BDD 技术定义并测试微服务及 Web Service API。虽然我在书中已经讨论过这方面的内容，但如今在“客户驱动契约”这一思想上又发展出了许多有趣的工具，例如 Pact 和 Pacto，它们实际上就是“可执行规范”的一种表现形式。

InfoQ：BDD这门实践的未来将会怎样发展？

John：我认为 BDD 在微服务技术中能够扮演一个重要的角色。打个比方，客户驱动契约测试是对微服务进行测试的一个良好开端，但它相对比较专注于低层次及测试。有许多 BDD 的概念可以整合到这个领域中，例如从这些 Web Service 契约中驱动及发现需求，并将报告返回客户驱动契约风格的自动化测试，以表示哪些 Web Service 是可用的、它们如何工作，以及它们是如何与高层次的业务需求相关联的。

此外，为了使可执行规范、活文档以及我称之为“特性覆盖”（不仅在报告中说明哪些测试已执行，并且说明哪些特性与功能已交付）的观念更为合理化，依然还有大量的工作需要完成。

BDD 的中心思想是协作以及通过具体的实例进行对话，这是理解一个问题领域的有效方式，它不会很快地被人遗忘。从技术层面上来说，这方面的工具一定能够不断地发展。而我已经很确定地看到，在所有层面编写可执行的规范这一方式已经逐渐成长为一种标准的技术实践。

可以使用优惠代码’smartinfoq’__，以 6__ 折的价格在 manning.com购买《BDD in Action_》一书的所有格式电子书。_

关于本书作者

John Ferguson Smart 是一位在敏捷技术实践方面广受赞誉的顾问、教练以及培训师，现居住在澳大利亚悉尼。他也是一位在需求发现、行为驱动开发、自动化测试、开发者最佳实践以及持续集成和持续交付方面具有突出贡献的国际性人才，帮助世界上的各个组织改善他们的内部协作以及技术实践，并且对开发流程和基础设施进行优化。John 也是一位著名的讲师，在各种国际性会议与聚会上进行过多次演讲。他也是《Java Power Tools》以及《Jenkins: The Definitive Guide》这两本广受好评的书籍的作者，这两本书都由O’Reilly 出版。同时他也是《BDD in Action》一书的作者，本书由Manning 出版。

查看英文原文： Interview and Book Review: BDD In Action