說起BDD，你會想到什么？

在剛接觸 BDD（Behavior Driven Development，行為驅動開發）的時候，我以為就是用 Cucumber 這樣的工具來編寫場景用例，從而實現自動化測試，甚至很長時間分不清 BDD 和 ATDD (Acceptance test driven development)到底有什么區別。那么，BDD 真的就是用來做自動化測試的嗎？本文就來跟大家分享一下我理解的 BDD。

為什么要 BDD？

“開發軟件系統最困難的部分就是準確說明開發什么” (“The hardest single part of building a software system is deciding precisely what to build” — No Silver Bullet, Fred Brooks) 。

場景一：業務分析人員覺得自己分析的需求已經寫的很清晰了，并且跟技術人員進行了足夠的溝通，可是開發完 sign off 的時候，發現所開發的功能還是跟期望有差距。

場景二：開發團隊辛辛苦苦開發完一個功能，滿懷信心的去給客戶展示的時候，才發現原來客戶需求的功能不是這樣的。

這些場景是不是似曾相識？為什么會這樣？第一個場景是開發團隊內部技術人員跟需求分析人員的理解有偏差，導致大家理解的需求其實是不一樣的；第 二個場景是開發團隊沒有真正理解產品經理／客戶所提出來的真實需求，導致開發的產品跟需求不一致。其實，產生這兩個不一致的真正原因是因為不同角色有著不 同的領域知識，說著不同的語言，大家在溝通的時候，如果都用自己領域語言，必然會產生溝通代溝，導致理解的不一致性。

領域知識不同、語言不通導致溝通障礙，這個客觀存在的問題該如何解決呢？BDD 正是為此而生。

BDD 是什么？

BDD 的提出者 Dan North 強調 BDD 不是關于測試的，它是在應用程序存在之前，寫出用例與期望，從而描述應用程序的行為，并且促使在項目中的人們彼此互相溝通。

要給 BDD 下個清晰易懂的定義很難，包括大師們也這么認為，這里試著總結以下幾點：

1. 關注的是業務領域，而不是技術：BDD 強調用領域特定語言（DSL, domain specific language）描述用戶行為，定義業務需求，而不會關心系統的技術實現。
2. 不是工具，強調的是一種協作方式：BDD 要求各個角色共同參與系統行為的挖掘和定義，以實現對業務價值的一致理解。
3. 不是關于測試的：BDD 源自 TDD,但重點不是關于測試，所強調的溝通與協作可以指導更好的做自動化測試。
4. 全棧敏捷方法：BDD 促使團隊所有角色從需求到最后的測試驗證，進行高度的協作和溝通，以交付最有價值的功能。

BDD 怎么做？

用例場景的描述格式“GIVEN… WHEN… THEN… ”對大家都不陌生，但用這個格式寫出好的用例卻是非常的難，尤其是新手。這里總結幾點供大家參考：

1. 業務層抽取，業務語言描述

根據業務層的數據流，在每個數據停留點進行縱切，抽取出一個個用例場景。描述語言一定是業務領域可懂的，不要涉及任何實現相關的技術細節。所描述的場景一定是從業務層抽象出來，體現真實業務價值的。

2. 技術人員可懂，自動化友好

所描述的用例場景要能驅動開發，必須要讓技術人員易于理解；要指導自動化測試，還得要求對于自動化的實現是友好的。這一點似乎是跟第一點有些矛 盾，但我們嚴格遵守 BDD 的格式要求還是可以做到的。其中，GIVEN 從句描述的是場景的前提條件、初始狀態，通常是一種現在完成時態；WHEN 從句是采取某個動作或者是發生某個事件，一定是動詞，通常是一般現在時；THEN 從句用“應該…(should be…)”來描述一種期望的結果，而不用斷言（assert），后者與測試關聯更緊密。

3. 數據驅動，需求實例化

抽象的業務語言描述的需求，往往由于太抽象而缺失掉很多關鍵信息，導致不同人員對需求理解的不一致。想要既抽象又能包含細節信息，就需要采用需 求實例來描述。簡單說來，就是給場景用例舉例說明。舉例就會需要列舉數據，如果在場景用例描述里邊直接添加數據實例，那樣的用例將會很混亂，可讀性和可維 護性都非常差。如果我們能夠在描述場景的用例里邊用一些變量來代替，把變量對應的值（數據）提取出來存為一個表格或者獨立的文件，這樣將會使得用例的可讀 性很好，而且也不會缺失細節信息（數據），后期的維護和修改也較為方便。這就是數據驅動的方法來描述實例化的需求。

看幾個例子，大家體會一下：

場景一：檢查收件箱，可以看出第三個清晰明了且能體現業務價值，比較符合上面的要求。

場景二：限制非法用戶查看某些受限內容，BDD 強調什么（What），而不是怎么（How），第二個寫的比較好。

場景三：添加圖書到購物車并計算總額

BDD 的工具有 Cucumber、JBehave、Twist、Concordion 等，工具的優缺點和使用方法，網上都有豐富的文檔可參考，在此不作介紹。

BDD 有什么好處？

BDD 的作用是把利益關系人、交付團隊等不同方面的項目相關人員集中到一起，形成共同的理解，共同的價值觀以及共同的期望值。它可以幫助我們：

• 關注用戶行為
• 交付最有用的功能
• 在團隊內部維護一致的術語
• 探究需求實例
• 編寫和維護需求
• 創建活的文檔
• 消除協作與溝通障礙

什么樣的項目適合 BDD？

• 簡單的一次性項目，溝通交流成本都較低的情況下，沒有必要使用 BDD；
• 業務比較輕量，重在技術方面的項目，可以只使用 TDD，或者簡單的白板上的 BDD，不需要在 BDD 工具記錄需求用例文檔；
• 業務復雜、團隊成員較多的項目，溝通成本高，BDD 很有必要。

常見疑惑

1. BDD 與 TDD/ATDD

TDD 是測試驅動開發，ATDD 是驗收測試驅動開發，都是關于測試的，是與所開發的系統緊密聯系的。而 BDD 則不同，前面提到過 BDD 不是關于測試的，著重關注需求、關注客戶的業務價值，所描述的需求用例是可以獨立于軟件系統存在的，因為客戶的業務是始終存在的，不取決于是否有軟件系統 來支撐。

2. BDD 與 SBE

SBE (Specification By Example，實例化需求)是在 BDD 之后由 Gojko 提出來的，也是關于需求的，主要強調通過列舉實例發現需求中的缺失概念。BDD 也是關注需求的，同樣會使用實例來描述行為。兩者的本質沒有區別，只是概念的差異。