在過去十年中，軟件開發中從級聯到敏捷方法的轉變迎來了一個持續測試和變革的時代。這種質量工程的新方法使開發人員能夠引入新的更改並防止錯誤或故障阻礙應用程序的可擴展性，從而使開發過程更加動態化。
在敏捷開發環境中操作的任何人都可能熟悉術語行為驅動開發 (BDD) 和測試驅動開發 (TDD)。由於這兩個術語發音相似，因此很容易將一個與另一個混淆或將它們視為同義詞。然而，事實並非如此。
儘管 BDD 和 TDD 都是測試優先的方法，但過程卻明顯不同。在 TDD 中，書面測試用例用於檢查應用程序功能的有效性。另一方面，BDD 從最終用戶的角度測試系統的行為。
那麼，這些差異如何轉化為測試結果和應用程序穩健性？每種方法的優缺點是什麼？並且兩者可以結合使用嗎？讓我們仔細看看 BDD 與 TDD：
什麼是TDD？
TDD 或測試驅動開發是一種從開發人員的角度適合編程實踐的測試方法。在這種方法中，質量保證工程師在為應用程序的每個微小功能設計和編寫測試用例後，使用 TDD 測試方法來解決一個簡單的單一問題——代碼是否有效？
這裡的意圖很簡單——測試新編寫的代碼是否有效，只有在 TDD 測試失敗的情況下才修改或重寫它。因此，這種測試方法有助於在很大程度上減少測試腳本的重複，使其成為一種非常流行的優化敏捷開發生態系統的技術。
由於它是一種測試優先的方法，因此通常在編寫代碼之前編寫自動化測試腳本。TDD過程需要以下步驟：
- 開發人員根據預先指定的要求編寫自動化測試腳本。
- 執行測試。由於這些測試是在編寫代碼之前開發的，因此在某些情況下往往會失敗。在其他情況下，它可能會給出錯誤的結果，這是測試驅動開發技術的最大已知缺點。
- 代碼被重構以成功通過預先設計的測試。
測試驅動開發的好處：
沒有 TDD 有其缺點和缺點，但其優點遠大於缺點。使用 TDD 技術的一些主要好處包括：
- 它在很短的時間內探索錯誤、錯誤和故障非常有效。
- 由於測試返回有針對性的見解，因此它減少了返工應用程序的任何組件所需的工作量和時間。
- 開發人員可以獲得更快的反饋。
- 促進生態系統，以實現更有能力和更清潔的設計。
- 提高編程效率。
- 有助於開發易於維護、靈活且廣泛的代碼。
- 可以利用 TDD 方法精確而自信地更改任何應用程序的大型架構。
- 鼓勵在代碼開發過程中進行協作和知識共享，為整個團隊提供足夠的訪問權限和專業知識，即使在關鍵團隊成員缺席的情況下也能繼續進行。
什麼是 BDD？
業務驅動開發或 BDD 是測試驅動開發 (TDD) 技術的擴展。它建立在 TDD 方法論的核心測試前端精神之上。在這種情況下，測試的重點是系統的行為。應用程序的不同功能或組件是根據這些行為預測開發的。用於 BDD 測試的最常用方法被稱為 Given-When-Then。
這意味著 – 假設用戶輸入了有效的登錄憑據，您可以預測下一步，即用戶通過單擊按鈕完成登錄過程的時間，以及顯示成功驗證消息的結果。
從上述過程中可以明顯看出，BDD 測試是使用一種共享語言進行的——或者簡單地說，用易於理解的英語——使團隊中的每個人都能輕鬆準確地理解功能行為。
BDD 在降低開發週期 (SDLC) 任務後期階段的錯誤和錯誤風險方面也發揮著至關重要的作用。考慮到此時調試的成本有多高，BDD 的主要優勢之一是它能夠消除與需求相關的歧義，從而確保全面的開發工作保持一致和同步。
這是通過使用簡單的英語來定義要求和方法並使用不同的方式來說明現實世界的場景來實現對最終目標的清晰理解來實現的。通過這些功能，BDD 技術為技術和非技術團隊提供了一個共同的平台，用於協作和交流知識和想法。
行為驅動的開發優勢：
很明顯，與 TDD 相比，BDD 在許多方面是一種更進化的方法。它為開發過程帶來的一些主要好處包括：
- 通過依賴非技術語言來定義目標和要求，促進更廣泛的目標推廣。
- 一種更具成本效益的測試方法。
- 減少驗證和糾正部署後缺陷的成本和工作量。
- 從開發人員和最終用戶的角度關注應用程序行為。
BDD 和 TDD 之間的主要區別
BDD 和 TDD 似乎具有廣泛的相似性，這不僅是因為它們聽起來相似的命名法，還因為它們的目的。但技術旨在測試軟件應用程序。在這兩種方法中，測試都是在代碼之前編寫的。兩者都可以用作自動化測試框架的一部分，以防止故障、錯誤和錯誤。
即便如此，這兩種開發測試技術在以下方面彼此明顯不同：
測試範圍
BDD 旨在從最終用戶的角度測試應用程序的行為方式，而 TDD 則單獨測試應用程序的小組件的功能。TDD 關注特定方法的結果，而 BDD 關注更複雜場景的結果。
簡而言之，TDD 說：“我需要以特定方式執行預先設計的測試，而不必擔心結果。” 另一方面，BDD 說：“只要結果在預定義條件下是正確的，過程就無關緊要。”
測試方法
TDD 是一種更傳統的軟件測試方法，由開發人員和 QA 工程師完成，沒有任何利益相關者（如產品經理）的參與。與此形成鮮明對比的是，BDD 更具包容性，促進了產品經理、測試工程師、開發人員以及其他利益相關者之間的協作，以實現所需的功能。
反饋與溝通
在反饋和溝通過程方面，BDD 也比 TDD 具有明顯的優勢。由於行為描述和場景都是用簡單的英語描述的，因此不僅對於非技術團隊成員而且客戶更容易理解測試過程並與技術團隊分享他們的觀察和評論。
這為更開放的雙向通信線路鋪平了道路，可以簡化發送、接收和合併反饋的過程，最終提高軟件設計和測試的質量。在 TDD 中，理解測試的能力僅限於熟練的程序員。雖然這種方法限制了溝通外展，但它用代碼質量來彌補它。
編寫測試
如前所述，在 BDD 和 TDD 中，編寫測試先於開發過程。然而，不同之處在於這些測試試圖完成什麼。在 TDD 中，編寫測試是為了滿足開發人員和他們編寫的代碼。在 BDD 中，測試旨在滿足開發人員和最終用戶的需求。
TDD 和 BDD 最佳實踐
TDD 和 BDD 都有其獨特的用途和優勢。為了最佳地利用這些，採用正確的實踐和方法來部署這些測試方法中的每一種是至關重要的。以下是 TDD 和 BDD 最佳實踐的概要：
TDD 最佳實踐：
- 根據需求編寫自動化測試用例。
- 在開發的代碼上運行自動化測試用例。
- 如果為測試用例開發的代碼未能產生預期的結果，則對其進行返工以獲得預期的結果。
- 重新運行測試用例以確定它們是否正確實現。
- 根據測試用例結果重構您的代碼，使其可重用並增強其可讀性。
- 重複此循環，直到為特定軟件實現了所有測試用例。
BDD 的最佳實踐：
- 用簡單的英語編寫應用程序行為的場景，以便業務分析師、產品負責人、QA 和開發人員等都能理解。
- 使用自動化腳本將行為場景轉換為編程測試。
- 實現作為行為場景基礎的功能編碼器。
- 運行該行為以檢查它是否成功。如果是，請轉到下一個場景。如果不是，則修復功能代碼錯誤，直到實現所需的行為。
- 重新組織或重構代碼以提高可讀性和可重用性。
- 重複這些步驟以在您的應用程序中實現不同的行為場景。
![筆記] TDD/BDD and Test Double. 這篇筆記分幾個重點| by R. H. | hobo engineer | Medium](https://i-blog.csdnimg.cn/blog_migrate/e9b0421bdf4896dd50cfde7c4c8d8c22.png)
BDD 和 TDD 可以一起工作嗎？
BDD 和 TDD 有其不同之處和相似之處，但它們並不相互排斥。雖然敏捷團隊使用一個而沒有另一個的情況並不少見，但讓兩者一起工作可以確保在測試應用程序用例時有更高的效率，從而對他們的性能產生更大的信心。
例如，開發團隊可以使用 BDD 方法與 TDD 一起實施更高級別的測試，不僅從開發人員的角度處理技術上的細微差別，而且還評估應用程序的行為。為了實現細節，開發人員可以創建單獨的測試單元來維護不同組件的健壯性。考慮到可以在應用程序的不同位置使用相同的組件，這可能特別有益。
如何在單個框架中組合和利用 BDD 和 TDD 的合適示例是 Rspec，它是一種為測試 Ruby 代碼而編寫的測試工具。Ruby 應用程序使用 BDD 和 TDD 原則進行測試。
首先，測試過程基於用簡單語言指定文本描述。開發人員添加 TDD 元素來測試某些特定組件。是選擇 BDD 而不是 TDD 還是反之亦然，或者使用這兩種方法的組合是由應用程序或組織的個人需求決定的選擇。
也就是說，當您已經在進行 TDD 測試時嘗試使用 BDD（反之亦然）可以為軟件開發過程增加價值。將兩者結合使用更容易的原因是您不需要更改或返工現有的做法。所需要的只是建立測試框架以適應另一個。
結論
了解 BDD 和 TDD 技術如何工作可以幫助軟件開發人員以及其他利益相關者通過專注於滿足他們需求的最佳測試策略來改進敏捷開發過程。根據項目的性質和所需的結果，您可以在這兩種技術之間進行選擇或混合使用，以提高測試覆蓋效率。
Other Agile Resources
- Large Scale Scrum
- Agile & Scrum Basics
410
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
