行为驱动开发(Behavior-Driven Development， BDD)的概念来自于测试驱动开发，强调使用DSL(Domain Specific Language，领域特定语言)描述用户行为，定义业务需求，是需求分析人员、开发人员与测试人员进行沟通的有效方法。DSL是一种编码实现，相比自然语言更加精确，又能以符合领域概念的形式满足所谓“活文档(Living Document)”的要求。可以说，行为驱动开发将编码实现与业务行为描述完美地结合起来，走出了一条业务分析人员、开发人员与测试人员都能接受的中庸之道。

行为驱动开发的核心在于“行为”。当业务需求被划分为不同的业务场景，并以“Given-When-Then”的形式描述出来时，就形成了一种范式化的领域建模规约。编写领域特定语言的过程，其实就是不断发现领域概念的过程。因此，采用BDD进行开发，最重要的产出不是可以自动运行的验收测试，而是它提供了团队交流的平台，并在其约束之下完成了领域建模。由于团队的不同角色都参与了这个过程，就保证了领域模型的一致性与准确性。

在进行行为驱动开发时，需要避免两种错误的倾向：

从UI操作去表现业务行为

描述技术实现而非业务需求

例如，我们要编写“发送邮件”这个业务场景，可能会写成这样：

Scenario: send email 

Given a user "James" with password "123456" 

And I sign in 

And I fill in "mike@dddpractice.com" in "to" textbox  

And fill in "test email" in "subject" textbox 

And fill in "This is a test email" in "body" textarea 

When I click the "send email" button 

Then the email should be sent sucessfully 

And shown with message "the email is sent sucessfully" 

该业务场景描写的不是业务行为，而是用户通过UI进行交互的操作流程。这种方式实则是让用户界面捆绑了你对领域行为的认知。准确地说，这种UI交互操作并非业务行为，例如上述场景中提到的button与textbox控件，与发送邮件的功能并没有关系。或许换一个UI设计，使用的控件又完全不同了。

那么换成这样的写法呢?

Scenario: send email 

Given a user "James" with password "123456" 

And I sign in after OAuth authentification 

And I fill in "mike@dddpractice.com" as receiver 

And "test email" as subject 

And "This is a test email" as email body 

When I send the email 

Then it should connect smtp server 

And all messages should be composed to email 

And a composed email should be sent to receiver via smtp protocal 

该场景的编写暴露了不必要的技术细节，如连接到smtp服务器、消息组合为邮件、邮件通过smtp协议发送等。对于BDD而言，场景应该关注于做什么(what)，而不是怎么做(how)。如果在业务分析过程中，纠缠于技术细节，就可能导致我们忽略了业务价值。在业务建模阶段，业务才是重心，不能舍本逐末。

那么，该怎么写?当我们使用DSL编写业务场景时，不要考虑任何UI操作，甚至需要抛开业已设计好的UI原型，也不要考虑任何技术细节。在编写好业务场景之后，可以验证：如果我们更换了UI设计，调整了UI布局，是否需要修改业务场景?同理，如果我们改变了技术实现方案，是否需要修改业务场景?如下场景采用业务行为的形式编写：

Scenario: send email 

Given a user "James" with password "123456" 

And I sign in 

And I fill in a subject with "test email" 

And a body with "This is a test email" 

When I send the email to "Mike" with address "mike@dddpractice.com" 

Then the email should be sent sucessfully 

我们要将DSL描述的场景视为一种可读的需求规格(Specification)，通过它准确地表现领域知识，就可以帮助我们提炼出隐含的领域概念。例如：

Scenario: validate the given date for reporting period  

Given the reporting period as prior 13 month to report month 

And the reporting month is "April 2018" 

When user choose the "April 2017" 

Then validation result is true 

When user choose "March 2017" 

Then validation result is false 

场景描述中的ReportingPeriod蕴含了与财务报表相关的领域知识，即有效报表周期为13个月，ReportingPeriod自身应该履行验证给定日期是否有效的职责。

【本文为51CTO专栏作者“张逸”原创稿件，转载请联系原作者】