TDD＆BDD的差異
什麼是TDD？
TDD很好理解，翻譯就是測試驅動開發，它的流程也真的如字面上所翻譯，就是先寫測試，用測試程式來驅動開發真正要交付的系統程式碼。
實做說穿了就下列幾個步驟，任何系統拆解開來，都是由多個功能（feature)所組成，例如人事系統，可能會有出勤功能，薪資功能等等，所以我們要做的第一件事，就是把功能各個擊破。一次只需要專注在一個功能上。
承上，我們選定一個功能（feature)，舉例來說，假如是出勤功能，要滿足這個功能，會有很多的使用者情境(scenario)，如上班簽到情境、下班簽退情境、加班申請情境等等，使用者的情境採用Give When Then的格式撰寫，完成之後我們會得到一個紅燈，因為目前系統並未支援這個使用案例，所以這也是程式人員價值的所在，要實做production code讓系統可以支援這個案例，透過最簡單、直覺的方式撰寫程式，讓測試案例可以通過，便可以得到一個綠燈，接著仗著程式碼有測試程式保護作靠山，開始肆無忌憚的對它做重構的動作。完成之後，就不斷以這樣的循環直至完成所有的使用者情境(scenario)，就代表完成了這個(feature)。
緊接著，就可以前進到下一個功能，再繼續循環到所有功能完成，便代表完成了這個系統。
什麼是BDD？
BDD是行為驅動開發，它的架構跟TDD非常類似，當我們在跟使用者做需求訪談時，使用者會跟我們講一個非常溫暖的故事(但你想聽的重點大概只有不到10%)。大致上是在描述系統尚未完成時，他們是如何進行原本的業務，但遇到一些困難，讓他們非常困擾，為了改善這個流程，所以希望系統能帶給他們什麼樣的功能。為何說他溫暖呢，因為他講的一定會非常生動，要讓你身歷其境才能夠深刻瞭解他的痛XD，但實際上，對系統分析所需要的資訊來說，裡面有過多的形容詞和雜音。所以，身為一個合格的PO需要傾聽使用者的心聲後，過濾掉多餘的形容詞，產生出使用者故事(User Story)，來跟使用者確認是否能解決他們的痛點。簡單的格式範例如下：
- In order to 產生某某好處
- as a XXX人員
- I want 系統提供某某功能
定義好故事之後，便可針對這個故事去定義這個故事如何算是"已完成(done)"的驗收案例。
這些東西跟TDD簡單的對照就是，User Story相當於Feature，驗收案例相當於scenario。持續的循環把驗收案例完成，來證明User Story已經實做，然後再循環到所有User Story完成，就可以證明這個系統到達可交付的階段。
講了那麼多 到底差在哪？
就我自己本身的理解，ATDD、BDD、TDD他們根本就是一家人。只有差別在參與討論的角色不同而已，但因程式設計師參與最多的環節是TDD，所以就自然比較理解TDD。
可是回歸到問題的本身，除了前人遺留下來的程式碼你想幫他補測試可以直接從TDD切入之外，其實也不建議補，大部分的情況都會面臨到一個問題，我的測試案例怎麼來？
所以，想通這一點之後，便要反璞歸真，任何的需求都是來自使用者，畢竟，用系統的人絕對不是程式設計師自己，所以，一個符合使用者需求的系統，即使設計的再爛，他的價值也遠超過彈性，架構漂亮，效能快卻不符合需求的系統。
因此，我認為BDD是相對上層的框架，是以使用者與系統互動的行為當成基礎來驅動開發系統，所以不可以談及程式碼設計的細節，而是要與使用者以領域知識(domain knowledge)為溝通語言，來描述整個系統的開發，所以我認為BDD應該是以三個循環互相推動，讓系統能夠前進。
第一層循環是專案擁有者(PO)與使用者做第一階段的溝通，這個階段是ATDD，使用者會描述他的痛點(why要做這件事)，他身為什麼角色(who要用這個系統），希望如何做來幫他解決問題（what 功能），在這個階段，PO必須要傾聽完使用者需求後，把它分析成User Story，並且導引使用者說的更清楚明白所有的驗收案例，來為這個User Story賦予"完成"的定義。
第二層循環是專案擁有者(PO)與開發人員做第二階段的溝通，此時就可談到系統設計的細節，比如說，會有哪些欄位，在這個階段是可以討論的，這階段可以把User Story轉換成Feature，驗收案例則轉換成scenario，並且以Given、When、Then的格式描述要如何完成每個scenario。
第三階段循環就是由開發人員將這些Scenaio轉換成Steps defication，就可以順利得到紅燈，再來就進入開發人員最熟悉的TDD範疇了，用最快最簡單的方式通過紅燈，接著重構程式碼。循環到所有紅燈通過，就完成了系統開發。世界將會變得很美好....
我心目中的BDD，僅供參考
結論
由此看來TDD和BDD骨子裡都是一樣的基因，差別只在他們面對的對象不同而已，在面對不懂程式的使用者，直接看TDD牽扯到太多程式的細節，會變成無法溝通，而BDD就是為了這個需求而生，也是一塊重要的拼圖，藉由大家都看得懂得方式，以說人話來溝通，可以很容易的達成共識，避免之後程式設計師花了精力實做系統，卻跟使用者的想法有落差，而造成內耗。
當然，串起TDD和BDD兩者靈魂的便是專案的擁有者PO，這也是PO的價值所在，一個優秀的PO，可以讓需求方信任，讓程式設計師相挺，而造成三贏的局面;反之則是對立，互推責任，互踢皮球，造成三輸。
