[30天快速上手TDD][Day 23]BDD - Introduction
前言
前面先介紹了如何透過 ATDD ，透過 user story 來定義與管理使用者需求開始，透過驗收測試案例來定義一個 user story 什麼時候可以視為完成。
然而 user story 與驗收測試案例，都是由 domain specific language 來描述。這與實際的程式碼來說，中間還有一段不小的落差。
該怎麼樣把中間的 gap 彌補起來，就是透過 BDD 的方式來進行。
本篇文章將針對 BDD 來做個簡單介紹。
介紹
前面三篇文章，提到了在軟體開發流程的一開始，一切的起源都是源自使用者的需求，系統的存在是為了滿足使用者的需求，進而產生相關的效益。
而我們透過 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 的最後一塊拼圖。
以下是整個開發流程的相關環節，一環扣著一環：
- User Story：定義與管理使用者需求
- Acceptance Test Cases：定義 user story 的完成事項
- BDD 的 Feature 與 Scenario：描述 acceptance test cases 所對應的系統行為
- BDD 的 Step Template：用來放 TDD 的測試案例
- 進入 TDD 循環
原本的 unit test cases 與 integration test cases ，現在都由系統行為面來當作觸發點。滿足了這些系統行為，則代表滿足了 acceptance test cases ，則代表滿足了 user story ，則代表滿足了使用者需求。
進而維持團隊一定的開發節奏，進度明顯可見，結果一翻兩瞪眼，只要測試都通過，就可以保證那一個 scenario 有被完成，程式碼也只具備 test cases/scenario 的需求，多的沒有，少的沒少。
ATDD 與 BDD ，是筆者之前在用 TDD 貫穿整個開發流程中，最缺的一環。原因在於：
- 不知道測試案例怎麼來
- 測試案例怎麼符合使用者需求
- 怎麼降低使用者需求到系統程式碼中間的落差
下一篇文章，則介紹要使用 BDD ，我們可以透過什麼工具來實作。
blog 與課程更新內容，請前往新站位置：http://tdd.best/
