行为驱动开发使用体验

行为驱动开发（BDD）认为软件开发是现如今企业运营的根本，有助于改善企业利益相关者和软件开发者之间的沟通。 Kevin Smith 在其一篇最近的博文中介绍了他使用 BDD 的工作经验。

在进行了多年的敏捷项目后，Dootrix 公司的技术总监和联合创始人 Smith 注意到了敏捷开发的一些共同缺点：

• 由于用户故事越来越多关注于用户以及他的软件需求，这样很容易让开发者忘记商业需求。
• 用户故事生命周期较短，因此很容易忘记一个应用程序的整体规范。
• 由于用户故事生命周期较短，基于用户故事的验收标准往往质量较低。
• 缺乏可以发现并解决业务问题的敏捷工具。
• 测试驱动开发（TDD）是目前常用的一种手段，但是往往这些测试仅仅验证了细节，而没有验证功能是否正确的实现了。

根据 Smith 过往的经验，BDD 可以帮助解决这些问题，尤其是在引入实例化需求（Specification by example）以及影响地图（Impact mapping）等概念的时候。

Smith 曾经实现了一个简单的改变，他将用户故事转换为一个更加偏向于 BDD 风格的形式，他认为通过这样可以让人们将关注点转移到商务价值上，并更多讨论它：

为了 < 实现利益 >，作为一个 < 角色 >，我需要 < 功能 >。

BDD 强调要使用具体的用例来减少歧义。这些用例有助于建立共同的认识，并找到丢失的功能。当编写验收标准时，可以用正式的语言 Gherkin 来写这些用例，并可以基于这些用例进行自动化测试。

构建软件的一个常见的挑战是如何创建正确合适的文档。由于 BDD 关注于用用例来解释行为，因此可以用于自动化生成文档。这个文档与实际实现的功能同步，我们通常称其为活文档。

虽然 Smith 认为 BDD 给我们带来了很多方便，但它还是存在一些潜在的缺点值得我们的注意：

• BDD 没有涉及到用户界面，所以我们还需要使用原型和其他的工具来保证界面完好设计。
• 有很多现成的工具可以测试编写的用例，但缺少可以管理运行哪个测试、何时运行的工具。
• 它很难开发一个很好的自动化测试套件，在短期内它较为昂贵。

Smith 最后指出 BDD 还是一个新兴的想法，因此缺乏如同敏捷方法一般的生态环境。不过他相信这是帮助人们在搭建软件的时候更好沟通的一个好方法。为了再一次激起人们对 BDD 的关注，他引用了 BDD 的作者 Dan North 的一句话：

BDD 是促进合作并通过实例探索的一大选择。

查看英文原文： Experiences with Behaviour-Driven Development