行为驱动开发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之类更专业的工具等等。