今天我們來介紹跟 TDD 相近的 BDD，這裡指的相近絕對不是只差一個字的相近。在 TDD 情況下，工程師們彼此間的討論與溝通是沒有問題的，但非技術人員，像是 PM、Designer 等，較難透過工程師所寫的程式碼了解並參與討論。

BBD 介紹

BDD，Behavior Driven Development，行為驅動開發，有別於 TDD 所強調的是工程師自身的程式碼技術，BDD 強調的是以人類的語言，來描述情境與功能，讓參與專案者的水平溝通更順暢。

一項專案的產生，絕對不是光靠工程師自身技術完成，在開發專案前中後期，都會需要與 PM、Designer 等非工程師背景人員進行溝通。

有時 PM 可能無法完全理解工程師們的語言，也就是程式碼。

如果你今天把你打完的規格或程式碼丟給 PM 看，PM 有辦法快速給予有效的回饋嗎？應該是不容易啦!那這樣會讓專案的效率降低以外，最讓人害怕的是，最後做出來的成品，有可能不是當初 PM 的真正意思，溝通上造成的落差導致認知的結果不一致。

當然整個專案牽扯到的人，不會只有 PM，一定還有其他 Developer 跟 QA，而且每個人都會針對自己的視角來看事情，勢必能發現其他人，包含工程師，看不到的問題。

如果不能理解工程師所做出來的東西，那勢必很難給予適當的回饋與調整。所以，BDD 的出現就是為了讓工程師以外的角色一起參與其中，讓專案的測試在規劃初期，就能符合大家想要的測試情境與條件，有好的開始，才能夠有好的結果。

要如何讓大家都明白彼此的話呢？

從工程師表達出來的語言一定含有大量工程師背景的術語，PM、Developer，不一定能夠馬上理解，如果在寫測試之前，有一份文件能夠讓所有人都看得懂，這個測試在什麼情況，什麼條件，預期會發生什麼事情，那該有多好？完全沒代溝啊！這就是 BDD 期望達成的目標。