關於 tdd practice ，我們在網路上蒐集到這些相關的討論、資訊與評價

什麼是 BDD?

BDD 是 Behavior Driven Development 的縮寫. 它和 TDD, exploratory testing 是 Agile Testing 最重要的三個新的 practice.

很多人都聽過這個名詞, 但是不知道他是什麼

Dan North 在 twitter 上用了這樣一句話來說明
“Using examples at multiple levels to create shared understanding and surface uncertainty to deliver software that matters.”

這裡有提到幾個重點

(1) examples
怎樣解釋需求是最有效的方式, 那就是舉些範例, 由範例來讓大家了解這個需求是怎麼運行的

(2) shared understandling
這個 practice 的重點是要達成共識. 如果你的 BDD 只是工程師自己寫寫自動化, 沒有 PO 或是客戶的加入, 那不能稱為是 BDD, 那只是你多寫了一些測試程式.

(3) surface uncertainty
那些範例需要寫出來? 是什麼地方需要有共同了解? 不是都寫些大家都知道的, 不確定的部分更是我們處理的重點.

(4) deliver software that matters
除了不確定的部分, 有價值的部分更是我們要優先釐清.

這樣有幫助你了解在實施 BDD 時, 什麼地方透別要注意嗎？

如何寫出人人有共識的需求 - 範例描述需求篇
https://kojenchieh.pixnet.net/blog/post/558923197-specbyexamplecourse
報名網址:
https://forms.gle/zqgPBEyCvcEhN6ms5

【壓箱寶都在這】
　
六月份有門新課，主題是【工程實踐與流程規範導入實務】，主要是提供給想要在公司、產品、部門、團隊中，來導入工程實踐（主軸就是極限開發, XP 的那一些），以及敏捷協作流程的策略。
　
※ 最適合的受眾是想未來想要擔任 internal coach, tech leader, team leader 或是導入的先驅人員。
　
大家或許對工程實踐跟敏捷協作很感興趣，自己也投入了不少時間在學習相關的知識，然而這門培訓不是為了再次告訴大家已知的資訊，例如什麼是單元測試、CI、TDD、重構、敏捷、Scrum，而是把重點擺在：
　
🎯 如何讓老闆買單
🎯 如何讓團隊買單
🎯 如何讓需求單位買單
🎯 如何在抗拒、時程、資源限制下，開始成功的第一步
🎯 導入的策略與整個 roadmap 的建議
　
知識，大家願意投資都可以獲得。然而在各種組織裡面導入的眉角，會碰到的問題，怎麼運用種子、對不同的角色該怎麼應對、對心裡抗拒的人員該怎麼幫助他們，這些需要大量的實務經驗累積，而這才是我真的想在這分享給大家的。
　
內容會涵蓋到：
💡技術、工程實踐面
💡不同角色在開發流程與協作面
💡導入與落地的策略（對需求單位、stakeholder/manager、開發團隊 該怎麼進行）
　
※ 這門課為了效果更好，採小班制，目前最多只再收 8 位，預計最多一年開一次，畢竟是在培養跟自己搶飯碗的人 XD
　
更多詳細資訊，請參考：
👉https://dotblogs.com.tw/…/engineering-practice-and-process-…

莫非定律 (Murphy's Law): 凡是可能出錯的事就一定會出錯

只要是程式, 就一定會有 bug.
因此 Agile 很強調 TDD, BDD, 持續整合 這些 practice

養成未雨綢繆的習慣, 以減低出錯的可能性