什麼是 BDD？

BDD 是一種讓軟體團隊協同工作的方式，透過以下方式縮小業務人員和技術人員之間的差距：

我們透過將協作工作重點放在具體的、真實世界的範例上來實現這一點，這些範例說明我們希望系統如何運作。我們使用這些範例在持續協作的過程中，從概念引導到實作。

BDD 和敏捷

我們假設你的團隊已經在使用某種敏捷方法，以像使用者故事這樣的小價值增量來規劃工作。BDD 不會取代你現有的敏捷流程，它會增強它。

將 BDD 視為你現有流程的一組外掛程式，它將使你的團隊更能實現敏捷的承諾：及時、可靠地發布可用的軟體，以滿足你的組織不斷變化的需求，這需要一些維護工作和紀律。

我們假設你希望能夠快速回應使用者的回饋，並且只做滿足這些需求的必要最少工作。

BDD 鼓勵以快速迭代的方式工作，不斷將使用者的問題分解成小塊，這些小塊可以盡快流經你的開發流程。

基本上，日常的 BDD 活動是一個三步驟的迭代流程

這個想法是讓每次變更都很小並快速迭代，每次當你需要更多資訊時，都向上移動一個層級。每次你自動化並實作一個新的範例時，你都為你的系統新增了有價值的東西，而且你已經準備好回應回饋了。

我們稱這些實務為 *探索*、*制定* 和 *自動化*。

隨著時間的推移，記錄的範例會成為一項資產，使你的團隊能夠繼續自信且快速地對系統進行變更。程式碼反映了文件，而文件反映了團隊對問題領域的共同理解。這種共同理解不斷發展。

關於這些實務有很多東西要學習。我們將在下面總結它們中的每一個。

建構軟體系統最困難的部分是精確地決定要建構什麼。

– Fred Brooks，《人月神話》

雖然文件和自動化測試是由 BDD 團隊產生的，但你可以將它們視為不錯的副作用。真正的目標是有價值的、可用的軟體，而達到這個目標的最快方法是透過參與想像和交付軟體的人員之間的對話。

BDD 幫助團隊在正確的時間進行正確的對話，以便你最大限度地減少在會議中花費的時間，並最大限度地提高你產生有價值的程式碼量。

我們使用稱為探索工作坊的結構化對話，該對話側重於從使用者角度來看系統的真實世界範例。這些對話增進了我們團隊對使用者需求的共同理解、關於系統應如何運作的規則，以及需要完成的工作範圍。

它也可能揭示我們理解上的差距，在我們知道該做什麼之前，我們需要更多資訊。

探索會議的仔細檢查通常會揭示可以從使用者故事的範圍中延遲的低優先級功能，幫助團隊以更小的增量工作，改善他們的工作流程。

如果你是 BDD 的新手，那麼探索是開始的正確地方。在掌握探索之前，你不會從其他兩種實務中獲得太多樂趣。

一旦我們從探索會議中確定了至少一個有價值的範例，我們現在就可以將每個範例制定為結構化文件。這為我們提供了一種快速的方式來確認我們確實對要建構的內容有共同的理解。

透過協作編寫這個可執行規格，我們建立了一種用於討論系統的共同語言。這有助於我們將問題領域術語一直使用到程式碼中。

現在我們有了可執行的規格，我們可以使用它來引導我們實作的開發。

一次採用一個範例，我們透過將其作為測試連接到系統來自動化它。由於我們尚未實作它所描述的行為，因此測試失敗。現在我們開發實作程式碼，使用內部系統元件行為的較低層級範例在需要時引導我們。

自動化範例的作用就像導軌，幫助我們保持開發工作步入正軌。

當我們需要稍後返回維護系統時，自動化範例將幫助我們了解系統目前正在做什麼，並安全地進行變更而不會無意中破壞任何東西。

這種快速、可重複的回饋減少了手動迴歸測試的負擔，使人們可以進行更感興趣的工作，例如探索性測試。

閱讀以下主題以深入了解並了解更多關於 BDD 的資訊。