介绍行为驱动开发

当定义了新项目的期望结果后，行为驱动开发 （BDD）有助于克服开发人员对构建产品需求的理解与业务人员对需求引起的技术困难理解之间的差距。其原因是两组之间的沟通得到了改善，Alistair Stead 和 Konstantin Kudryashov 两人都在Inviqa 工作，在他们的 BDD 入门指南中针对业务和技术人员做了解释。

Stead 和 Kudryashov 把 BDD 分成了两个主要的实践：用通用语言写用例来描述行为，以及用这些用例作为自动化测试的基础。结合这两个实践就可以为用户验证其功能性，以及在整个项目周期中系统的行为与所定义的一致。

Stead 和 Kudryashov 指出的 BDD 的关键元素包括：

• 创建目标，最好在项目开始的时候从业务的角度定义具体的，以及可衡量的目标。
• 影响地图（ Impact Mapping），是找到一种可以达到设定目标的、对业务最重要的那些功能的方法。影响地图可视化了为什么这些功能是需要的，以及为达到目标需要改变的那些行为。
• 复杂度分析，找到一种最适合开发与合作方法的方式，例如 Cynefin 。
• 用用例做计划，通过用例来描述业务规则，以及提供上下文来避免误解。这些用例接下来还应该转化成开发阶段所使用的测试用例。
• 通用语言（ Ubiquitous language），这是来自于领域驱动设计（Domain-Driven Design（DDD）） 方法的术语，指的是开发人员和业务人员为某个领域中的术语达到共同的理解，而使用的一种共享语言。
• 通过用例开发。通过一种形式语言和类似于 Cucumber 的自动化工具实现，用例可以转化成可执行的规范，从而验证实现的功能。
• BDD**** 循环。能够提供对系统大变更的支持。使用可执行的规范，并将单元测试作为系统的各个部分应该如何表现的对象规范，就能够获得可以处理任意大小规模变更的能力。

在一次对 Dan North （他在 2006 年左右开发了 BDD）的采访中，他强调 BDD 不是关于测试的，它是在应用程序存在之前，写出用例与期望，从而描述应用程序的行为，并且促使在项目中的人们彼此互相沟通。North 说明了保持人们互相亲近的重要性，分离式结构或跨地域团队是成功实施 BDD 一大障碍。

查看英文原文： Introducing Behaviour-Driven Development

感谢邵思华对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。