測試驅動開發 (TDD)和行為驅動開發 (BDD?) 都是軟件開發的測試優先方法。它們共享共同的概念和范式，植根于相同的哲學。在本文中，我們將重點介紹這兩種方法的共性、差異、優缺點。

什么是測試驅動開發（TDD）

測試驅動開發 (TDD) 是一種依賴于重復短開發周期的軟件開發過程：需求轉化為非常具體的測試用例。編寫代碼是為了使測試通過。最后，對代碼進行重構和改進，以確保代碼質量并消除任何技術債務。這個循環被稱為 Red-Green-Refactor 循環。

什么是行為驅動開發 (BDD)

行為驅動開發 (BDD) 是一個軟件開發過程，它鼓勵參與項目交付的所有各方之間的協作。它鼓勵以各方都能理解的通用語言對系統行為進行定義和形式化，并將此定義用作基于 TDD 的流程的種子。

TDD 和 BDD 之間的主要區別

測試驅動開發 (TDD)

在 TDD 中，我們有眾所周知的 Red-Green-Refactor 循環。我們從一個失敗的測試開始（紅色），并盡可能少地實現代碼以使其通過（綠色）。此過程也稱為測試優先開發。TDD 還增加了一個 Refactor 階段，這對整體成功同樣重要。

TDD 方法是由單元測試和后來的 TDD、敏捷軟件開發和最終極限編程的先驅之一的 Kent Beck 發現（或可能重新發現）的。

下圖很好地提供了一個易于理解的過程概述。然而，美在于細節。在深入研究每個單獨的階段之前，我們還必須討論 TDD 的兩種高級方法，即自下而上和自上而下的 TDD。

自下而上的 TDD

自底向上 TDD（也稱為 Inside-Out TDD）背后的理念是迭代地構建功能，一次只關注一個實體，在移動到其他實體和其他層之前鞏固其行為。

我們首先編寫單元級測試，繼續執行它們，然后繼續編寫高級測試，聚合低級測試的功能，創建所述聚合測試的實現，等等。通過逐層構建，我們最終將達到一個階段，即聚合測試是一個驗收水平測試，希望符合所要求的功能。此過程使其成為一種高度以開發人員為中心的方法，主要旨在使開發人員的生活更輕松。

自上而下的 TDD

自上而下的 TDD 也稱為外向內 TDD 或驗收測試驅動開發 (ATDD)。它采取相反的方法。我們開始構建一個系統，迭代地為實現添加更多細節。隨著重構機會變得明顯，迭代地將其分解為更小的實體。

我們首先編寫一個可接受級別的測試，然后進行最少的實現。該測試也需要逐步進行。因此，在創建任何新實體或方法之前，需要在適當級別進行測試。因此，我們迭代地改進解決方案，直到它解決了啟動整個練習的問題，即驗收測試。

這種設置使自上而下的 TDD 成為一種更加以業務/客戶為中心的方法。這種方法更難正確，因為它在很大程度上依賴于客戶和團隊之間的良好溝通。它還需要開發人員的良好公民身份，因為需要仔細考慮下一個迭代步驟。這個過程會及時加快，但確實有一個學習曲線。然而，好處遠遠超過任何負面影響。這種方法導致客戶和團隊之間的協作成為中心舞臺，一個具有非常明確的行為、明確定義的流程、專注于首先集成以及非常可預測的工作流程和結果的系統。

紅綠重構生命周期

有了上面討論過的關于如何處理 TDD 的高級愿景，我們可以自由地深入研究 Red-Green-Refactor 流程的三個核心階段。

紅色的

我們首先編寫一個測試，執行它（因此失敗），然后才開始執行該測試。在這里編寫正確的測試至關重要，就我們試圖實現的測試層達成一致也是如此。這將是驗收水平測試還是單元水平測試？這種選擇是自下而上和自上而下 TDD 之間的主要界限。

綠

在綠色階段，我們必須創建一個實現以使紅色階段中定義的測試通過。實現應該是盡可能最小的實現，使測試通過，僅此而已。運行測試并觀察它通過。

創建盡可能最小的實現通常是這里的挑戰，因為開發人員可能傾向于通過習慣的力量立即美化實現。這個結果是不可取的，因為它會產生技術包袱，隨著時間的推移，這將使重構更加昂貴，并可能基于重構成本扭曲系統。通過使每個實施步驟盡可能小，我們進一步強調了我們試圖實施的過程的迭代性質。此功能將賦予我們敏捷性。

另一個關鍵方面是紅色階段，即測試，是推動綠色階段的動力。任何實現都不應該由非常具體的測試驅動。如果我們采用自下而上的方法，這很自然。但是，如果我們采用自上而下的方法，那么我們必須更加認真，并確保在實現形成時創建進一步的測試，從而從驗收級別測試轉向單元級別測試。

重構

重構階段是 TDD 的第三個支柱。這里的目標是重新審視和改進實施。優化了實現，提高了代碼質量，消除了冗余。

重構對許多人來說可能具有負面含義，被視為純粹的成本，在第一次就修復了不正確的事情。這種看法源于更傳統的工作流程，其中重構主要只在必要時進行，通常是在技術包袱達到無法維持的水平時，從而導致冗長、昂貴的重構工作。

然而，在這里，重構是工作流的固有部分，并且是迭代執行的。這種靈活性極大地降低了重構的成本。代碼沒有完全重做。相反，它正在緩慢發展。此外，根據定義，重構的代碼包含在測試中。在之前的代碼迭代中已經通過的測試。因此，可以放心地進行重構，從而進一步加快速度。此外，這種改進代碼庫的迭代方法允許緊急設計，這大大降低了過度設計問題的風險。

行為不應該改變是至關重要的，我們不會在重構階段添加額外的功能。這個過程允許以極大的信心和敏捷性進行重構，因為根據定義，相關代碼已經被測試覆蓋。

行為驅動開發 (BDD)

如前所述，TDD（或自下而上的 TDD）是一種以開發人員為中心的方法，旨在生成更好的代碼庫和更好的測試套件。相比之下，ATDD 更加以客戶為中心，旨在提供更好的整體解決方案。我們可以將行為驅動開發視為 ATDD 的下一個邏輯進展。Dan North在 TDD 和 ATDD 方面的經驗導致他提出了 BDD 概念，其想法和主張是將 TDD 和 ATDD 的最佳方面結合在一起，同時消除他在這兩種方法中發現的痛點。他發現，具有描述性的測試名稱很有幫助，而且測試行為比功能測試更有價值。

Dan North 將 BDD 簡潔地描述為“使用多個級別的示例來創建共享理解和表面確定性以交付重要的軟件”，做得很好。

這里的一些關鍵點：

• 我們關心的是系統的行為
• 測試行為比測試特定的功能實現細節更有價值
• 使用通用語言/符號在領域專家、開發人員、測試人員、利益相關者等之間形成對預期和現有行為的共同理解。
• 當每個人都能夠理解系統的行為、已經實現了什么以及正在實現什么并且保證系統滿足所描述的行為時，我們實現了表面確定性

BDD 將責任更多地放在客戶和團隊之間富有成效的協作上。正確定義系統的行為變得更加關鍵，從而導致正確的行為測試。這里的一個常見陷阱是對系統將如何實施行為做出假設。這個錯誤發生在被實現細節污染的測試中，因此使其成為功能測試而不是真正的行為測試。這個錯誤是我們想要避免的。

行為測試的價值在于它測試了系統。它不關心它是如何實現結果的。這種設置意味著行為測試不應隨時間而改變。除非行為本身需要作為功能請求的一部分進行更改。功能測試的成本效益更為顯著，因為此類測試通常與實現緊密耦合，以至于代碼的重構也涉及測試的重構。

然而，更大的好處是保留了表面確定性。在功能測試中，代碼重構也可能需要測試重構，這不可避免地會導致失去信心。如果測試失敗，我們不確定原因可能是什么：代碼、測試或兩者兼而有之。即使測試通過，我們也不能確信之前的行為已經被保留。我們所知道的是測試與實現相匹配。這個結果的價值很低，因為最終客戶關心的是系統的行為。因此，我們需要測試和保證的是系統的行為。

基于 BDD 的方法應該導致完整的測試覆蓋，其中行為測試使用通用語言向所有各方充分描述系統的行為。與功能測試相比，即使完全覆蓋也不能保證系統是否滿足客戶的需求，重構測試套件本身的風險和成本只會隨著覆蓋率的增加而增加。當然，通過自上而下地從行為測試到更多功能測試來利用這兩種方法，將為行為測試帶來表面確定性的好處。此外，功能測試以開發人員為中心的好處也抑制了功能測試的成本和風險，因為它們只在適當的地方使用。

在直接比較 TDD 和 BDD 時，主要變化是：

• 簡化了測試什么的決定；我們需要測試行為
• 我們利用一種通用語言來縮短另一層通信并簡化工作；利益相關者定義的用戶故事是測試用例

出現了框架和工具的生態系統，以允許跨團隊進行基于通用語言的協作。以及通過利用行業標準工具來集成和執行測試等行為。這方面的例子包括 Cucumber、JBehave 和 Fitnesse 等等。

適合工作的工具

正如我們所看到的，TDD 和 BDD 之間并沒有真正的直接競爭。將 BDD 視為 TDD 和 ATDD 的進一步發展，它帶來了更多以客戶為中心，并進一步強調了客戶與技術團隊在流程的所有階段之間的溝通。這樣做的結果是一個系統，其行為符合所有相關方的預期，以及一個測試套件，以人類可讀的方式描述系統的許多行為，每個人都可以訪問并易于理解。反過來，該系統不僅對已實施的系統，而且對系統的未來更改、重構和維護提供了非常高的信心。

同時，BDD 很大程度上基于 TDD 流程，并進行了一些關鍵更改。雖然客戶或團隊的特定成員可能主要參與系統的最頂層，但其他團隊成員（如開發人員和 QA 工程師）會在他們以自己的方式在頂層工作時從 BDD 有機地轉變為 TDD 模型。下來時尚。

我們期待以下主要好處：

• 把痛苦向前推進
• 客戶和團隊之間協作的責任
• 客戶和團隊領導之間共享的共同語言，以分享理解
• 實施精益的迭代過程
• 保證交付的軟件不僅可以正常工作，而且可以按定義工作
• 通過緊急設計避免過度設計，從而通過盡可能最小的解決方案達到預期的結果
• 表面確定性允許快速和自信的代碼重構
• 測試具有與生俱來的價值 VS 創建測試只是為了滿足任意代碼覆蓋率閾值
• 測試是完整描述系統行為的活文檔

在某些情況下，BDD 可能不是合適的選擇。在某些情況下，所討論的系統技術性很強，可能根本不面向客戶。它使需求與功能的聯系比與行為的聯系更緊密，從而使 TDD 可能更適合。

采用 TDD 還是 BDD？

最終，問題不應該是采用 TDD 還是 BDD，而是哪種方法最適合手頭的任務。很多時候，這個問題的答案是兩者兼而有之。隨著越來越多的人參與到更重要的項目中，不言而喻的是，在整個項目生命周期的不同級別和不同時間都需要這兩種方法。TDD 將為技術團隊提供結構和信心。BDD 將促進和強調所有相關方之間的溝通，并最終交付滿足客戶期望的產品，并提供所需的表面確定性，以確保對未來進一步發展產品的信心。

通常情況下，這里沒有靈丹妙藥。相反，我們擁有的是一些非常有效的方法。兩者的知識將使團隊能夠根據項目的需要確定最佳方法。進一步的經驗和執行的流暢性將使團隊能夠在整個項目生命周期中根據需要使用其工具箱中的所有工具，從而實現最佳的業務成果。