測試驅動(dòng)開(kāi)發(fā) (TDD)和行為驅動(dòng)開(kāi)發(fā) (BDD?) 都是軟件開(kāi)發(fā)的測試優(yōu)先方法。它們共享共同的概念和范式，植根于相同的哲學(xué)。在本文中，我們將重點(diǎn)介紹這兩種方法的共性、差異、優(yōu)缺點(diǎn)。

什么是測試驅動(dòng)開(kāi)發(fā)（TDD）

測試驅動(dòng)開(kāi)發(fā) (TDD) 是一種依賴(lài)于重復短開(kāi)發(fā)周期的軟件開(kāi)發(fā)過(guò)程：需求轉化為非常具體的測試用例。編寫(xiě)代碼是為了使測試通過(guò)。最后，對代碼進(jìn)行重構和改進(jìn)，以確保代碼質(zhì)量并消除任何技術(shù)債務(wù)。這個(gè)循環(huán)被稱(chēng)為 Red-Green-Refactor 循環(huán)。

什么是行為驅動(dòng)開(kāi)發(fā) (BDD)

行為驅動(dòng)開(kāi)發(fā) (BDD) 是一個(gè)軟件開(kāi)發(fā)過(guò)程，它鼓勵參與項目交付的所有各方之間的協(xié)作。它鼓勵以各方都能理解的通用語(yǔ)言對系統行為進(jìn)行定義和形式化，并將此定義用作基于 TDD 的流程的種子。

TDD 和 BDD 之間的主要區別

測試驅動(dòng)開(kāi)發(fā) (TDD)

在 TDD 中，我們有眾所周知的 Red-Green-Refactor 循環(huán)。我們從一個(gè)失敗的測試開(kāi)始（紅色），并盡可能少地實(shí)現代碼以使其通過(guò)（綠色）。此過(guò)程也稱(chēng)為測試優(yōu)先開(kāi)發(fā)。TDD 還增加了一個(gè) Refactor 階段，這對整體成功同樣重要。

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

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

自下而上的 TDD

自底向上 TDD（也稱(chēng)為 Inside-Out TDD）背后的理念是迭代地構建功能，一次只關(guān)注一個(gè)實(shí)體，在移動(dòng)到其他實(shí)體和其他層之前鞏固其行為。

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

自上而下的 TDD

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

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

這種設置使自上而下的 TDD 成為一種更加以業(yè)務(wù)/客戶(hù)為中心的方法。這種方法更難正確，因為它在很大程度上依賴(lài)于客戶(hù)和團隊之間的良好溝通。它還需要開(kāi)發(fā)人員的良好公民身份，因為需要仔細考慮下一個(gè)迭代步驟。這個(gè)過(guò)程會(huì )及時(shí)加快，但確實(shí)有一個(gè)學(xué)習曲線(xiàn)。然而，好處遠遠超過(guò)任何負面影響。這種方法導致客戶(hù)和團隊之間的協(xié)作成為中心舞臺，一個(gè)具有非常明確的行為、明確定義的流程、專(zhuān)注于首先集成以及非?？深A測的工作流程和結果的系統。

紅綠重構生命周期

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

紅色的

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

綠

在綠色階段，我們必須創(chuàng )建一個(gè)實(shí)現以使紅色階段中定義的測試通過(guò)。實(shí)現應該是盡可能最小的實(shí)現，使測試通過(guò)，僅此而已。運行測試并觀(guān)察它通過(guò)。

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

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

重構

重構階段是 TDD 的第三個(gè)支柱。這里的目標是重新審視和改進(jìn)實(shí)施。優(yōu)化了實(shí)現，提高了代碼質(zhì)量，消除了冗余。

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

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

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

行為驅動(dòng)開(kāi)發(fā) (BDD)

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

Dan North 將 BDD 簡(jiǎn)潔地描述為“使用多個(gè)級別的示例來(lái)創(chuàng )建共享理解和表面確定性以交付重要的軟件”，做得很好。

這里的一些關(guān)鍵點(diǎn)：

• 我們關(guān)心的是系統的行為
• 測試行為比測試特定的功能實(shí)現細節更有價(jià)值
• 使用通用語(yǔ)言/符號在領(lǐng)域專(zhuān)家、開(kāi)發(fā)人員、測試人員、利益相關(guān)者等之間形成對預期和現有行為的共同理解。
• 當每個(gè)人都能夠理解系統的行為、已經(jīng)實(shí)現了什么以及正在實(shí)現什么并且保證系統滿(mǎn)足所描述的行為時(shí)，我們實(shí)現了表面確定性

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

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

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

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

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

• 簡(jiǎn)化了測試什么的決定；我們需要測試行為
• 我們利用一種通用語(yǔ)言來(lái)縮短另一層通信并簡(jiǎn)化工作；利益相關(guān)者定義的用戶(hù)故事是測試用例

出現了框架和工具的生態(tài)系統，以允許跨團隊進(jìn)行基于通用語(yǔ)言的協(xié)作。以及通過(guò)利用行業(yè)標準工具來(lái)集成和執行測試等行為。這方面的例子包括 Cucumber、JBehave 和 Fitnesse 等等。

適合工作的工具

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

同時(shí)，BDD 很大程度上基于 TDD 流程，并進(jìn)行了一些關(guān)鍵更改。雖然客戶(hù)或團隊的特定成員可能主要參與系統的最頂層，但其他團隊成員（如開(kāi)發(fā)人員和 QA 工程師）會(huì )在他們以自己的方式在頂層工作時(shí)從 BDD 有機地轉變?yōu)?TDD 模型。下來(lái)時(shí)尚。

我們期待以下主要好處：

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

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

采用 TDD 還是 BDD？

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

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