行为驱动开发

• 2003年11月，由Dan North命名于伦敦，在其发表的“敏捷规格，BDD和极限测试交流”一文中，Dan North对BDD给出了如下定义：BDD是第二代的、由外及内的、基于拉动(pull)的、多方利益相关者的(stakeholder)、多种可扩展的、高度自动化的敏捷方法。它描述了一个交互循环，可以具有带有良好定义的输出（即工作中交付的结果）：已测试过的软件。(BDD is a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.) 同年，Dan North创建了第一个BDD框架JBehave[https://jbehave.org/]。

• 2007年，Dan North为Ruby创建了一个名为RBehave的故事级BDD框架，该框架后来被集成到RSpec项目中。

• 2008 年，参与了围绕BDD进行的首轮讨论的克里斯马茨，提出了特性注入(Feature Injection)的想法，BDD可以覆盖分析空间并提供从初期的展望到编码和发布的整个软件生命周期过程的改造。

• 2010年，David Chelimsky、Dave Astels、Bryan Helmkamp、Dan North，Zach Dennis五个人，以合作开发的RSpec为基础，一起撰写出版了“The RSpec Book: Behavior Driven Development with RSpec, Cucumber, and Friends”这本书。

• 2013年在对Dan North的一次采访中[https://www.youtube.com/watch?v=g5WpUJk8He4]， BDD又被解释为: 它使用例子来说明应用程序的行为…… 并针对这些例子进行交流。(It's using examples to talk through how an application behaves... And having conversations about those examples.)

• RSpec中的第一个基于故事的框架后来被Aslak Hellesøy于2008年开发的Cucumber所取代。

• Capybara是目前比较流行的BDD测试框架之一，Capybara通过模拟真实用户如何与您的应用程序交互来帮助您测试Web应用程序。它与运行测试的驱动程序无关，并带有内置的Rack::Test和Selenium支持，并能通过外部gem支持WebKit。

BDD诞生的初衷是去重新思考单元测试和验收测试的方法，以期许避免曾经出现过的问题。通过与干系人的讨论取得对预期的软件行为的清醒认识。通过用自然语言书写非只有程序员可读的测试用例，扩展了测试驱动开发（TDD）方法。行为驱动开发（BDD）人员使用统一的领域语言来描述他们的代码的目的。这让开发者得以把精力集中在代码应该怎么写，而不是技术细节上，而且也最大程度的减少了将代码编写者的技术语言与商业客户、用户、干系人、项目管理者等的领域语言之间来回转换、翻译的代价。

BDD VS TDD

TDD发现的问题

• 由于代码重构时，必须相应去重构测试过程，导致测试资产极其脆弱，同时自动化测试资产的维护成本很高；

• 开发人员与团队其他成员之间的沟通问题——一些开发人员发现很难有效地描述他们每天编写的自动化测试。这种缺乏沟通可能导致其他团队成员质疑和争论此类活动的价值；

• 开发人员很难估计他们何时会完成所有的自动化测试——因为答案是“取决于”，这取决于编写的类和方法的数量；

• 测试人员的重复测试工作——由于开发人员实现的自动化测试通常对团队中的非开发人员不可见，因此测试人员通常执行许多可能已经被开发人员的自动化测试覆盖的测试。

采用BDD的优势

• 团队事先就要实施的行为达成一致，之后就没有讨论任何测试价值的余地；

• 团队预先决定哪些行为由开发人员实现，哪些行为由测试人员执行；

• 团队可以更准确地向管理层提供估计——因为测试不依赖于编码的类和方法的数量；

• BDD通常有较少的测试资产并且这些资产相对比较健壮。所以当对代码进行重构时，要重构的测试代码就没有那么多。另外虽然BDD的测试资产较少，但仍然可以类似于TDD那样保证测试覆盖率 - 因为BDD的测试对象是整体行为 - 而不是单个方法或功能；

• 在BDD中每一个软件组件的测试过程都是透明的，包括测试人员和开发人员在内的所有人都可以看到，因此避免了TDD那样的重复性测试工作。

单元测试和验收测试

BDD的做法包括：

• 确立不同干系人要实现的远景目标

• 使用特性注入方法绘制出达到这些目标所需要的特性

• 通过由外及内的软件开发方法，把涉及到的干系人融入到实现的过程中

• 使用例子来描述应用程序的行为或代码的每个单元

• 通过自动运行这些例子，提供快速反馈，进行回归测试

• 使用“应当(should)”来描述软件的行为，以帮助阐明代码的职责，以及回答对该软件的功能性的质疑

• 使用“确保(ensure)”来描述软件的职责，以把代码本身的效用与其他单元(element)代码带来的边际效用中区分出来。

• 使用mock作为还未编写的相关代码模块的替身。

行为规范的用户故事

开发人员与干系人之间的交互要写成双方都能懂的用户故事，用户故事的一般构成是：

• 标题 一个显式的标题。

• 叙述 一个简短的介绍性的部分使用以下结构:

  • 作为一个 :人或角色将受益于功能;

  • 我想要的 :功能;

  • 这 :利益或价值的特性。

• 验收标准 每个特定的描述 场景 下面的叙述结构:

  • 鉴于 :初始上下文的场景中,在一个或多个条款;

  • 当 :事件触发场景;

  • 然后 :预期结果,在一个或多个从句。 BDD没有任何正式的要求去指导如何去写用户故事,但它坚持认为每个团队使用BDD时，需要想出一个简单、标准化的格式去记录包括上面元素的用户故事。

一个非常简短的例子格式:

标题：退货和换货进入库存。

作为店主，我想在退货或换货时将商品添加回库存，以便跟踪库存。

场景1：退回退款的物品应添加到库存中。考虑到一位客户之前从我那里买了一件黑色毛衣，而我的库存中有三件黑色毛衣，当他们退回黑色毛衣要求退款时，那么我的库存中应该有四件黑色毛衣。

场景2：交换的物品应返回到库存。考虑到一位客户之前从我这里购买了一件蓝色衣服，我库存中有两件蓝色衣服和三件黑色衣服，当他们将蓝色衣服换成黑色衣服时，我库存中应该有三件蓝色衣服和两件黑色衣服。

1. https://en.wikipedia.org/wiki/Behavior-driven_development

2. https://lizkeogh.com/2007/06/13/bdd-tdd-done-well

3. https://www.methodsandtools.com/archive/entreprisebdd.php