行为驱动开发BDD概要
BDD脱胎于TDD
行为驱动开发(Behavior-Driven Development,简称BDD),是在测试驱动开发(Test-Driven Development,TDD)基础上发展而来的一种软件开发方法。TDD最大的弊端,是面对一大堆的功能需求和用例时,往往会感到无从下手。另一方面,由于TDD更侧重于测试本身,因此容易忽视对业务需求的表达,最终沉溺于琐碎细节而无法自拔。
BDD避免了信息丢失
与传统的软件开发方法相比,BDD的本质在于尽可能避免在需求描述、用例撰写、代码实现、测试等各环节衔接、转译过程中发生的信息丢失。为此,BDD以用例Use Case和示例Example为核心,借助Gherkin等一些特有概念和一系列BDD特有工具,以更贴近业务场景的方式,实现软件需求的完整实现。二者的比较如下图所示。
传统软件开发
BDD开发
BDD流程
BDD的每个迭代可以表述为:
- 规划整个系统,得到抽象的业务目标Business Goal
- 将业务目标细化为若干个具体的功能需求Feature
- 采取Given-When-Then三段式编写Gherkin,用具体的场景示例Example描述和演示特定的功能
- 将Example转换为可执行的Specification
- 将Specification再拆解为更低层次的、逼近代码实现的Low-Level Specification与测试Test
- 从Low-Level Specification中得到代码实现,并析取活动文档Living Documentation
发掘Business Goal与Feature
采用Why-Who-How-What四步法发掘Business Goal
- Why:出于何种原因要开发此系统?
- Who:谁将从系统中受益?谁是系统的用户?谁会影响系统的开发?
- How:怎样才能更便捷、更容易地达成业务目标?
- What:系统能做哪些工作来实现业务目标?
而在从Business Goal发现Feature时,则采用了Why-Who-What-How四步法进行Feature的粒度细分,得到最终的用户故事。
其中,Capability是“用户需要能做什么”,而Feature是“软件能提供怎样的帮助”
BDD工具
在.NET平台,从Example到可执行的Specification,有SpecFlow可用;再到Low-Level Specification,有NUnit、RSpec等工具可用。
.NET平台下的BDD开发
在Visual Studio集成环境下,可以按以下步骤实施BDD。
准备工作
为Visual Studio安装SpecFlow扩展插件
安装扩展后,将可以在项目中添加用于编写Gherkin的Feature文件
为项目添加SpecFlow支持包
SpecFlow.NUnit集成了SpecFlow与NUnit,更方便我们编写相关的测试,所以选择安装它即可。如果要使用最新版本的SpecFlow与NUnit,则请分别选择安装(NUnit3.0与SpecFlow1.9.0貌似有冲突,测试无法被识别)。如果你喜欢其他的单元测试框架,请选择并安装相应类型的package。
撰写Gherkin
Gherkin,是BDD中采取特定格式、用于描述特定的Feature、形式为特定业务场景示例Example的文本。它较之需求规范Specification更具体明了,有点类似Use Case,但更具体生动,且既可用作测试脚本,又可作为归档的内容。
添加Gherkin
为项目添加新项,选择“SpecFlow Feature File”
编辑Gherkin
打开Feature文件,修改模板内容,得到具体业务需求的描述。其中Feature是功能描述(描述用的文本将自动作为SpecFlow测试的类名),Scenario是具体的业务场景(描述用的文本将自动作为SpecFlow测试名),接着是Given-When-Then的三段式Example描述(描述用的文本将自动作为SpecFlow生成的分步Step的方法名)。
生成可执行的Specification
可执行的Specification,是用来确认业务需求规范是否已被正确实现的自动化测试方法。
每一组Specification,对应Gherkin里的一个Given-When-Then的三段式场景Scenario。三段式的每一个分句,都将对应一个具体的测试方法,这被叫作分步Step。每个Step的方法骨架可借由SpecFlow等BDD工具自动生成,之后再手工修改即可。
SpecFlow+NUnit的组合,可以很容易地编写出可测试的Step,在Gherkin文本里的Given-When-Then等关键字上点击右键,选择“Generate Step Definitions”即可。在Attribute里出现的(.*)是占位符,类似正则析取参数。
在Build项目后,我们打开单元测试窗口,即可发现SpecFlow测试的踪影。由于此时每个分步Step里并没有我们实际的代码,因此我们运行测试时,会提示Step尚未被实现。
为了让SpecFlow的测试真正动起来,还需要修改Step的实现。简单演示如下:
新增Account类
namespace BDDExercise{public class Account {public decimal Balance { get; set; } public void Withdraw(decimal amount) {if (Balance - amount >= 0) Balance -= amount; } public void Deposit(decimal amount) {if (amount > 0) Balance += amount; } public Account(decimal amount) {if (amount > 0) Balance = amount; } }}
修改Step方法
using NUnit.Framework;using TechTalk.SpecFlow; namespace BDDExercise{ [Binding]public class TransferringMoneyBetweenAccountsSteps {private Account _currentAccount;private Account _savingAccount; [Given(@"my Current account has a balance of (.*)")]public void GivenMyCurrentAccountHasABalanceOf(decimal p0) { _currentAccount = new Account(p0); } [Given(@"my Savings account has a balance of (.*)")]public void GivenMySavingsAccountHasABalanceOf(decimal p0) { _savingAccount = new Account(p0); } [When(@"I transfer (.*) from my Current account to my Savings account")]public void WhenITransferFromMyCurrentAccountToMySavingsAccount(decimal p0) { _currentAccount.Withdraw(p0); _savingAccount.Deposit(p0); } [Then(@"I should have (.*) in my Current account")]public void ThenIShouldHaveInMyCurrentAccount(decimal p0) { Assert.AreEqual(_currentAccount.Balance, p0); } [Then(@"I should have (.*) in my Savings account")]public void ThenIShouldHaveInMySavingsAccount(decimal p0) { Assert.AreEqual(_savingAccount.Balance, p0); } }}
运行测试
编写Low-Level Specification
如果说此前可执行的Specification还是一个Scenario的简单映射,那么这里的Low-Level Specification则可以理解为TDD里的单元测试了。这一步的工作,就是仁者见仁、智者见智了,需要根据具体的业务规则去逐个编写,并保证足够的覆盖率,以驱动整个功能的逐步实现。
Low-Level Specification与之前Specification分割得到的Then分句相比,Then里放简单的断言,再用Low-Level Specification更细粒度的单元测试来弥补Then的不足。
生成Living Documentation
归档主要还是依赖自动化的工具,比如VS自带的测试报告或者SpecLog之类更专业的工具等等。
转载于:https://www.cnblogs.com/Abbey/p/4999634.html
行为驱动开发BDD概要相关推荐
- bdd行为驱动开发 java_行为驱动开发(BDD)如何与领域驱动设计(DDD)结合?
BDD是从TDD发展过来的,也属于DDD中一种描述业务的无处不在的统一语言,它的描述格式是: As a [Role] I want [Feature] so that [benefit] 用中文的意思 ...
- 优美的测试代码 - 行为驱动开发(BDD)
可理解的代码非常重要,测试代码也是如此.在我看来,优秀的测试代码,必须做到一个重要的事情就是保持测试逻辑的清晰.一个完整的测试案例通常包括三个部分: 1. SetUp 2. Exercise 3. V ...
- 行为驱动开发BDD和Cucunber简介
测试驱动开发(TDD) 1.测试驱动开发,即Test-Driven Development(TDD),测试驱动开发是敏捷开发中的一项核心实践和技术,也是一种设计方法论.TDD的原理是在开发功能代码之前 ...
- [PHP]用PHPUnit进行行为驱动开发(Behaviour-Driven Development)
PHPUnit的介绍可以翻翻前面几篇文章. 本文参考文献: [Astels2006] A New Look at Test-Driven Development 在[Astels2006] A New ...
- 测试驱动开发_DevOps之浅谈测试驱动开发
"测试驱动开发(Test-Driven Development, TDD),以测试作为开发过程的中心,它要求在编写任何产品代码之前,先编写用于定义产品代码行为的测试,而编写的产品代码又要以使 ...
- python行为驱动测试开发_行为驱动开发在 Python 开发测试中的应用
行为驱动开发 (BDD) 简介 行为驱动开发是什么? 说到行为驱动开发(BDD),无可避免的要提到敏捷里面的测试驱动开发(TDD),TDD 的主要思想是"代码即文档",其倡导的流程 ...
- jbehave_使用JBehave,Gradle和Jenkins的行为驱动开发(BDD)
jbehave 行为驱动开发 (BDD)是一个协作过程 ,产品所有者,开发人员和测试人员可以合作交付可为业务带来价值的软件. BDD是 测试驱动开发 (TDD) 的合理下一步 . 行为驱动的发展 本质 ...
- 使用JBehave,Gradle和Jenkins的行为驱动开发(BDD)
行为驱动开发 (BDD)是一个协作过程 ,产品负责人,开发人员和测试人员可以合作交付可为企业带来价值的软件. BDD是 测试驱动开发 (TDD) 的合理下一步 . 行为驱动的发展 本质上,BDD是一种 ...
- BDD(行为驱动开发)
BDD的重点是通过与利益相关者的讨论取得对预期的软件行为的清醒认识.它通过用自然语言书写非程序员可读的测试用例扩展了测试驱动开发方法.行为驱动开发人员使用混合了领域中统一的语言的母语语言来描述他们的代 ...
最新文章
- vs合并项目_线性混合效应模型 VS 方差分析
- 四种常见的 POST 提交数据方式
- win10 计算机休眠后无法唤醒,win10休眠后无法唤醒怎么办 win10系统怎么设置休眠时间...
- mongodb添加创建修改时间_mongodb副本集生产环境下部署案例,推荐一个主两个从三台机器...
- Java后端--25--内存数据库Redis讲解
- mysql 中如何增加查询排序性能
- 根据日期参数查询润乾报表
- 【工程测试与训练】使用 DDRNet 测试、训练cityscapes数据集、训练自己的数据集
- U3D性能优化之MeshBaker(带光照)
- 软考中级-数据库系统工程师复习知识点汇总
- 秒杀活动,怎么设计全套技术方案
- 武汉_金山wps Java 一面 二面
- noip2016 day1 t2 天天爱跑步
- 记一个windows预览体验计划0x800bfa07错误问题
- 版本 3.1(最终版)
- 随机森林用matlab实现,matlab实现随机森林
- JSON解析(java)
- 前端知识的浅薄了解2
- c++函数模板,有默认参数的函数
- 实现在线预览PDF的几种解决方案