前面先介紹了如何透過ATDD，透過user story來定義與管理使用者需求開始，透過驗收測試案例來定義一個user story什麼時候可以視為完成。

然而user story與驗收測試案例，都是由domain specific language來描述。這與實際的程式碼來說，中間還有一段不小的落差。

該怎麼樣把中間的gap彌補起來，就是透過BDD的方式來進行。

本篇文章將針對BDD來做個簡單介紹。

上一篇文章：[Day 22]ATDD - ATDD的循環
本系列文章專區
＠前言
前面三篇文章，提到了在軟體開發流程的一開始，一切的起源都是源自使用者的需求，系統的存在是為了滿足使用者的需求，進而產生相關的效益。

而我們透過user story來定義與管理使用者需求，透過驗收測試案例來定義一個user story什麼時候可以稱為完成。

使用驗收測試案例來當作「使用者需求」與「系統如何完成使用者需求」中間的橋樑，是一件很棒的事。

然而，user story與acceptance test cases都是使用domain specific language來描述，但是開發人員卻是需要使用程式語言（這邊以C#為例）來完成系統，這中間的gap仍有一大段距離，該怎麼彌補這一段距離，以避免開發人員撰寫的系統，無法直接match驗收測試案例，以致於無法確切的滿足使用者需求。

如圖所示（抱歉，時間有點趕，畫的有點醜）：

因此，這篇文章要講的是BDD(Behavior-driven development)，透過BDD，來當作驗收測試案例與系統之間的橋樑。

＠What - 什麼是BDD
BDD 的全名為 Behavior-driven development ，在 2003 年由 Dan North 所命名，用來作為 TDD 的輔助。

BDD是透過DSL(Domain-specific language)來描述系統的行為。

透過屬於該Domain的表達方式，來描述系統的Feature與使用者的Scenario，並且依據這些Scenario產生對應的code flow template，接著可結合Unit Test的3A原則(Arrange, Act, Assert)，來驗證系統功能是否有滿足這些Scenario。

＠Why - 為什麼要使用BDD
因為使用者的需求，要轉變成系統的程式碼，中間的落差相當大。

BDD的效益在於，能讓使用者、測試人員與開發人員，可以用一樣的方式來描述與了解需求，並且降低將人話轉換成程式碼的成本。

最重要的目的，則是讓開發人員在開發系統時，還是可以專注在使用者的需求。

＠When - 什麼時候使用BDD
當撰寫好驗收測試案例，建立好「可行走的骨架」，也就是系統雛形。開始準備著手開發實際的程式碼前，使用BDD 來描述「驗收測試案例」所對應的「系統行為與腳本」。

＠Who - BDD該由誰來撰寫
筆者的建議是由開發人員主導，測試人員輔助，確定這樣的Scenario是否為測試人員所預期的，是否滿足了驗收測試案例。

確認完畢後，開發人員就可以直接從code template著手進行TDD。

＠Where - BDD的腳本、程式碼該放在哪
BDD的腳本，其實就是產生測試程式的骨架，只是是使用DSL來描述罷了。

而BDD的內容，其實就是TDD的測試案例，可能包含了整合測試與單元測試的範疇。

所以BDD的專案，可直接視為整合測試專案或單元測試專案，筆者是建議這兩者要分開，以便開發時可以迅速執行單元測試，在持續整合的server上，則可以執行到完整的測試程式。

＠小結
其實在頗久之前，筆者就留意到了 BDD 這個東西，當時就是 TDD, DDD, BDD 這類的專有名詞不斷出現。之前覺得很酷，透過 DSL 就可以用人話來輔助設計出程式與測試程式。

但覺得離現實生活還是太遙遠了，連單元測試怎麼寫都是問題，TDD 都還不知道怎麼進行，直接跳到 behavior ，實在太艱難了。

隨著經驗的累積，單元測試、整合測試與重構，總算比較能夠上手並運用在實際的專案上，卻在 TDD 上，碰到了一點難題。

TDD 不論技術面、概念面、流程面，我想都沒什麼太大問題，問題出在：
『測試案例』如何由 QA 的產出，變成測試程式的 input ？

一來，沒 domain 還是不行，沒 domain 會導致只是 developer 在自 high 、自爽，寫出來的程式可能有完整的測試，功能也可正常運作，卻不是需求要的 feature 。

TDD 的 test cases ，淪為只是為了測試單元功能，或是用來測試較大或重要的行為。即使，過程是 TDD，概念是 TDD ，技巧是 TDD ，但卻還是少了 『模擬測試使用此物件的行為』。

在一個禮拜天早上，突然對 Agile 的 User Story 相當感興趣，不斷 survey 的過程中，突然想到了 BDD 這東西，這不就是用來結合 user story, ATDD 以及 TDD 的橋樑嗎？這個靈光一現，似乎找到了 TDD 的最後一塊拼圖。

以下是整個開發流程的相關環節，一環扣著一環：

1. user story：定義與管理使用者需求
2. acceptance test cases：定義user story的完成事項
3. BDD的Feature與Scenario：描述acceptance test cases所對應的系統行為
4. BDD的step template：用來放TDD的測試案例
5. 進入TDD循環

原本的unit test cases與integration test cases，現在都由系統行為面來當作觸發點。滿足了這些系統行為，則代表滿足了acceptance test cases，則代表滿足了user story，則代表滿足了使用者需求。

進而維持團隊一定的開發節奏，進度明顯可見，結果一翻兩瞪眼，只要測試都通過，就可以保證那一個Scenario有被完成，程式碼也只具備測試案例/Scenario的需求，多的沒有，少的沒少。

ATDD與BDD，是筆者之前在用TDD貫穿整個開發流程中，最缺的一環。原因在於：

1. 測試案例怎麼來
2. 測試案例怎麼符合使用者需求
3. 怎麼降低使用者需求到系統程式碼中間的落差

下一篇文章，則介紹要使用BDD，我們可以透過什麼工具來實作。