行为驱动开发使用体验

  • Jan Stenberg
  • 刘嘉洋

2016 年 9 月 13 日

话题:语言 & 开发架构文化 & 方法

行为驱动开发(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

语言 & 开发架构文化 & 方法