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

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

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

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

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

TDD 和 BDD 之間的主要區(qū)別 TDD BDD 重點 交付功能特性 交付預(yù)期的系統(tǒng)行為 方法 自下而上或自上而下（驗收測試驅(qū)動開發(fā)） 自頂向下 初始點 一個測試用例 用戶故事/場景 參與者 技術(shù)團隊 包括客戶在內(nèi)的所有團隊成員 語言 編程語言 通用語 過程 精益，迭代 精益，迭代 提供 符合我們測試標準的功能系統(tǒng) 一個按預(yù)期運行的系統(tǒng)和一個用人類通用語言描述系統(tǒng)行為的測試套件 避免 過度工程、低測試覆蓋率和低價值測試 偏離預(yù)期的系統(tǒng)行為 脆性 實現(xiàn)的變化可能導(dǎo)致測試套件的變化 如果需要更改系統(tǒng)行為，則僅需要更改測試套件 實施難度 自底向上比較簡單，自頂向下比較難 為所有相關(guān)方提供更大的學習曲線 測試驅(qū)動開發(fā) (TDD)

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

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

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

自下而上的 TDD

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

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

優(yōu)點 缺點 一次只關(guān)注一個功能實體 延遲整合階段 功能實體易于識別 實體需要暴露的行為數(shù)量尚不清楚 不需要高水平的愿景開始 實體之間無法正確交互從而需要重構(gòu)的高風險 有助于并行化 業(yè)務(wù)邏輯可能分布在多個實體中，使其不清楚且難以測試 自上而下的 TDD

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

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

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

優(yōu)點 缺點 一次只關(guān)注一個用戶請求的場景 獲得正確的斷言測試至關(guān)重要，因此需要業(yè)務(wù)/用戶/客戶和團隊之間的協(xié)作討論 流量很容易識別 依賴于 Stubbing、Mocking 和/或測試替身 重點是集成而不是實現(xiàn)細節(jié) 由于通過多次迭代識別流程，因此啟動較慢 一個實體需要暴露的行為數(shù)量是明確的 更有限的并行化機會，直到骨架系統(tǒng)開始出現(xiàn) 用戶需求、系統(tǒng)設(shè)計和實施細節(jié)都清楚地反映在測試套件中 可預(yù)見的 紅綠重構(gòu)生命周期

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

紅色的

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

綠

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

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

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

重構(gòu)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

適合工作的工具

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

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

我們期待以下主要好處：

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

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

采用 TDD 還是 BDD？

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

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

分享標題：了解TDD和BDD的差異
文章來源：http://www.rwnh.cn/news10/325060.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供軟件開發(fā)、標簽優(yōu)化、ChatGPT、網(wǎng)頁設(shè)計公司、企業(yè)網(wǎng)站制作、靜態(tài)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)