BDD/TDD差別是什麼？
TDD 重點回顧： 先寫測試再開發。 依循「紅燈／綠燈／重構」循環（Red/Green/Refactor）。 優點是在初期就確保測試程式的撰寫，而且更容易在初期定義出更貼近使用方的介面。 但 TDD 所撰寫出來的測試案例是一連串程式碼，過於偏重技術人員，不利與其他非技術的專案參與者討論，例如 PM (Product Manager) 或 PO (Product Owner)。此外，也不利產生一份如下圖這樣一目瞭然、容易閱讀的測試報告： 本篇將介紹 BDD (Behaviour-Driven Development) 如何補足這一哩路的不足，並延續上篇文章的範例來示範如何實戰 BDD。 三分鐘小測驗，了解你可以從哪開始進階軟體開發 TDD 的不足 —— 非技術人員難以參與討論 還記得上篇文章的範例，我們示範了一個「員工報表管理系統」的範例，而且在步驟一透過使用者角度思考， 在開發前就定義出更好的 API 介面 嗎？ 除了需求書表面要求的「撈出十年資深員工」功能，在使用者角度延伸思考到未來可能會有「撈出五年內的資淺員工」的需求，因而在開發前就定義出彈性更大的 API 介面，降低開始實作甚至產品上線後再回頭對 API 介面變動的風險。 「員工報表管理系統」是很簡單的範例，我們可以輕易判斷「撈出五年內的資淺員工」是個合理需求。但在現實專案中，當想到一個使用情境是需求規格書沒有定義到的， 通常需要與 PM (Product Manager) 或 PO (Product Owner) 進行討論 ，確認是否符合產品走向。 想像一下，這時候如果企圖直接用以下測試案例當作討論素材，與 PM 或 PO 等非程式開發人員進行討論： // file: src/test/emp-report.test.js const empReport = require ( '../main/emp-report' ) ; const expect = require ( 'expect' ) ; describe ( 'Get Report by Seniority' , ( ) => { it ( 'Get employees with...