行为驱动开发

维基百科,自由的百科全书
跳转至: 导航搜索

行为驱动开发(缩写BDD)是一种敏捷软件开发的技术,它鼓励软件项目中的开发者、QA和非技术人员或商业参与者之间的协作。BDD最初是由Dan North在2003年命名[1],它包括验收测试和客户测试驱动等的极限编程的实践,作为对测试驱动开发的回应。在过去数年里,它得到了很大的发展[2]

2009年,在伦敦发表的“敏捷规格,BDD和极限测试交流”[3]中,Dan North对BDD给出了如下定义:

BDD是第二代的、由外及内的、基于拉(pull)的、多方利益相关者的(stakeholder)、多种可扩展的、高自动化的敏捷方法。它描述了一个交互循环,可以具有带有良好定义的输出(即工作中交付的结果):已测试过的软件。

BDD的重点是通过与利益相关者的讨论取得对预期的软件行为的清醒认识。它通过用自然语言书写非程序员可读的测试用例扩展了测试驱动开发方法。行为驱动开发人员使用混合了领域中统一的语言的母语语言来描述他们的代码的目的。这让开发者得以把精力集中在代码应该怎么写,而不是技术细节上,而且也最大程度的减少了将代码编写者的技术语言与商业客户、用户、利益相关者、项目管理者等的领域语言之间来回翻译的代价。

Dan North创造了首个BDD框架:JBehave[1];之后是Ruby语言的基于故事的RBehave[4],后来被纳入了RSpec项目[5]。他还与大卫赫利姆斯基、Aslak Hellesøy及其他人开发了RSpec,并一起编写了《The RSpec Book: Behaviour Driven Development with RSpec, Cucumber, and Friends》。RSpec中第一个基于故事的框架,后来被主要由Aslak Hellesøy开发的Cucumber取代。

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

BDD 实践[编辑]

BDD的做法包括:

  • 确立不同利益相关者要实现的远景目标
  • 使用特性注入方法绘制出达到这些目标所需要的特性
  • 通过由外及内的软件开发方法,把涉及到的利益相关者融入到实现的过程中
  • 使用例子来描述应用程序的行为或代码的每个单元
  • 通过自动运行这些例子,提供快速反馈,进行回归测试
  • 使用“应当(should)”来描述软件的行为,以帮助阐明代码的职责,以及回答对该软件的功能性的质疑
  • 使用“确保(ensure)”来描述软件的职责,以把代码本身的效用与其他单元(element)代码带来的边际效用中区分出来。
  • 使用mock作为还未编写的相关代码模块的替身

特性注入[编辑]

一个公司可能有多个会带来商业利益的不同愿景,通常包括盈利、省钱或保护钱。一旦某个愿景被开发小组确定为当前条件下的最佳愿景,他们将需要更多的帮助来成功实现这个远景。

然后确定该愿景的主要利益相关者,会带入其他的利益相关者。每个相关者要定义为了实现该愿景他们需要完成的目标。例如,法务部门可能要求某些监管要得到满足。市场营销负责人可能要参加将使用该软件的用户的社区。安全专家需要确保该软件不会受到SQL注入的攻击。

通过这些目标,会定义出要实现这些目标所需要的大概的题目(theme)或者特性集合。例如,“允许用户排序贡献值”或“交易审计”。

从这些主题,可以得到用户功能以及用户界面的第一批细节。

由外及内[编辑]

BDD是由商业价值[7]--在应用开发中自然增长的商业利益--所驱动的。要认清这个利益的唯一方式,是通过用户接口(通常--但并不总是--图形界面,GUI)理解应用程序。

同样,每一段代码,从用户界面开始,可以视作它使用的其他模块代码的利益相关者。每个代码单元(element)通过与其他单元合作,提供部分行为,从而实现整个应用程序的行为。

引用[编辑]

外部链接[编辑]