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

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

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

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

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

TDD 和 BDD 之間的主要區(qū)別

測試驅(qū)動(dòng)開發(fā) (TDD)

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

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

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

自下而上的 TDD

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

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

自上而下的 TDD

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

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

這種設(shè)置使自上而下的 TDD 成為一種更加以業(yè)務(wù)/客戶為中心的方法。這種方法更難正確，因?yàn)樗诤艽蟪潭壬弦蕾囉诳蛻艉蛨F(tuán)隊(duì)之間的良好溝通。它還需要開發(fā)人員的良好公民身份，因?yàn)樾枰屑?xì)考慮下一個(gè)迭代步驟。這個(gè)過程會(huì)及時(shí)加快，但確實(shí)有一個(gè)學(xué)習(xí)曲線。然而，好處遠(yuǎn)遠(yuǎn)超過任何負(fù)面影響。這種方法導(dǎo)致客戶和團(tuán)隊(duì)之間的協(xié)作成為中心舞臺(tái)，一個(gè)具有非常明確的行為、明確定義的流程、專注于首先集成以及非常可預(yù)測的工作流程和結(jié)果的系統(tǒng)。

紅綠重構(gòu)生命周期

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

紅色的

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

綠

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

創(chuàng)建盡可能最小的實(shí)現(xiàn)通常是這里的挑戰(zhàn)，因?yàn)殚_發(fā)人員可能傾向于通過習(xí)慣的力量立即美化實(shí)現(xiàn)。這個(gè)結(jié)果是不可取的，因?yàn)樗鼤?huì)產(chǎn)生技術(shù)包袱，隨著時(shí)間的推移，這將使重構(gòu)更加昂貴，并可能基于重構(gòu)成本扭曲系統(tǒng)。通過使每個(gè)實(shí)施步驟盡可能小，我們進(jìn)一步強(qiáng)調(diào)了我們?cè)噲D實(shí)施的過程的迭代性質(zhì)。此功能將賦予我們敏捷性。

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

重構(gòu)

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

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

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

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

行為驅(qū)動(dòng)開發(fā) (BDD)

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

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

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

• 我們關(guān)心的是系統(tǒng)的行為
• 測試行為比測試特定的功能實(shí)現(xiàn)細(xì)節(jié)更有價(jià)值
• 使用通用語言/符號(hào)在領(lǐng)域?qū)＜摇㈤_發(fā)人員、測試人員、利益相關(guān)者等之間形成對(duì)預(yù)期和現(xiàn)有行為的共同理解。
• 當(dāng)每個(gè)人都能夠理解系統(tǒng)的行為、已經(jīng)實(shí)現(xiàn)了什么以及正在實(shí)現(xiàn)什么并且保證系統(tǒng)滿足所描述的行為時(shí)，我們實(shí)現(xiàn)了表面確定性

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

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

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

基于 BDD 的方法應(yīng)該導(dǎo)致完整的測試覆蓋，其中行為測試使用通用語言向所有各方充分描述系統(tǒng)的行為。與功能測試相比，即使完全覆蓋也不能保證系統(tǒng)是否滿足客戶的需求，重構(gòu)測試套件本身的風(fēng)險(xiǎn)和成本只會(huì)隨著覆蓋率的增加而增加。當(dāng)然，通過自上而下地從行為測試到更多功能測試來利用這兩種方法，將為行為測試帶來表面確定性的好處。此外，功能測試以開發(fā)人員為中心的好處也抑制了功能測試的成本和風(fēng)險(xiǎn)，因?yàn)樗鼈冎辉谶m當(dāng)?shù)牡胤绞褂谩?/p>

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

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

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

適合工作的工具

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

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

我們期待以下主要好處：

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

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

采用 TDD 還是 BDD？

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

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