BDD - 以BDD的方式進行TDD

---

---

在TDD中，“驗收測試”一詞具有誤導性。驗收測試實際上代表了系統預期行為。在敏捷實踐中，強調整個團隊的協作以及與客戶和其他利益相關者的互動。這導致了使用每個人都易於理解的術語的必要性。

TDD 讓你思考所需的行為，因此“行為”一詞比“測試”一詞更有用。BDD是測試驅動開發，其詞彙重點關注行為而非測試。

用Dan North的話來說，“我發現從以測試為中心思考轉向以行為為中心思考的轉變如此深刻，以至於我開始將TDD稱為BDD，或行為驅動開發。” TDD側重於事物如何運作，而BDD側重於我們為什麼要構建它。

BDD回答了開發人員經常面臨的以下問題：

這些答案導致以下故事框架：

故事框架

作為[角色]

我想要[功能]

以便[利益]

這意味著，“當功能被執行時，產生的利益歸屬於扮演角色的人。”

BDD進一步回答了以下問題：

這些答案導致以下示例框架：

示例框架

給定一些初始上下文，

當事件發生時，

則確保一些結果。

這意味著，“從初始上下文開始，當某個特定事件發生時，我們知道結果應該是什麼。”

因此，示例展示了系統的預期行為。這些示例用於說明系統的不同場景。

故事和場景

讓我們考慮Dan North關於ATM系統的以下示例。

故事

作為客戶，

我想要從ATM機上取款，

以便我不必在銀行排隊。

場景

這個故事有兩個可能的場景。

場景1 - 賬戶有餘額

給定賬戶有餘額

並且卡片有效

並且出納機中有現金

當客戶請求現金時

則確保賬戶被扣款

並且確保現金被髮放

並且確保卡片被退回

場景2 - 賬戶透支超過透支限額

給定賬戶透支

並且卡片有效

當客戶請求現金時

則確保顯示拒絕訊息

並且確保現金未被髮放

並且確保卡片被退回

兩個場景中的事件相同，但上下文不同。因此，結果也不同。

開發週期

BDD的開發週期採用從外到內的方法。

步驟1 - 編寫一個高層次（外部）業務價值示例（使用Cucumber或RSpec/Capybara），使其變為紅色。（RSpec在Ruby語言中生成一個BDD框架）

步驟2 - 為第一步實現編寫一個較低層次（內部）RSpec示例，使其變為紅色。

步驟3 - 實現透過該較低層次示例的最小程式碼，使其變為綠色。

步驟4 - 編寫下一個較低層次的RSpec示例，朝著透過步驟1的方向推進，使其變為紅色。

步驟5 - 重複步驟3和步驟4，直到步驟1中的高層次示例變為綠色。

注意 - 應牢記以下幾點：

• 紅/綠狀態是許可權狀態。

• 當您的低階測試為綠色時，您有權編寫新示例或重構現有實現。在重構的上下文中，您不得新增新功能/靈活性。

• 當您的低階測試為紅色時，您只有權編寫或更改實現程式碼以使現有測試變為綠色。您必須抵制編寫程式碼以透過您尚未存在的下一個測試的衝動，或實現您認為好的功能（客戶不會要求）。