# 什么是測試驅動開發（TDD）？ 實例教程 > 原文： [https://www.guru99.com/test-driven-development.html](https://www.guru99.com/test-driven-development.html) ## 什么是測試驅動開發？ **測試驅動開發（TDD）**首先，開發了測試，該測試指定并驗證代碼將執行的操作。 簡單來說，測試用例是在編寫代碼之前創建的。 TDD 的目的是使代碼更清晰，簡單且無錯誤。 測試驅動開發始于為應用程序的每個小功能設計和開發測試。 TDD 指示開發人員僅在自動測試失敗時才編寫新代碼。 這樣可以避免重復代碼。 TDD 的完整形式是測試驅動的開發。  TDD 的簡單概念是在編寫新代碼之前（開發之前）編寫并糾正失敗的測試。 這有助于避免重復代碼，因為我們一次編寫少量代碼以通過測試。 （測試只不過是我們需要測試以實現它們的需求條件）。 測試驅動開發是在實際開發應用程序之前開發和運行自動化測試的過程。 因此，TDD 有時也稱為**測試優先開發。** 在本教程中，您將了解有關- * [如何執行 TDD 測試](#2) * [TDDVs。 傳統測試](#3) * [什么是接受 TDD 和開發者 TDD](#4) * [通過敏捷模型驅動開發（AMDD）擴展 TDD](#5) * [測試驅動開發（TDD）與。 敏捷模型驅動開發（AMDD）](#6) * [TDD](#7) 的示例 * [TDD 的好處](#8) ## 如何執行 TDD 測試 以下步驟定義了如何執行 TDD 測試， 1. 添加測試。 2. 運行所有測試，然后查看是否有任何新測試失敗。 3. 編寫一些代碼。 4. 運行測試和重構代碼。 5. 重復。  **TDD 周期定義了** 1. 編寫測試 2. 使它運行。 3. 更改代碼以使其正確，即重構。 4. 重復過程。 **關于 TDD 的一些說明：** * TDD 既不涉及“測試”也不涉及“設計”。 * TDD 并不意味著“編寫一些測試，然后構建一個通過測試的系統。 * TDD 并不意味著“進行大量測試”。 ## TDDVs。 傳統測試 TDD 方法主要是一種規范技術。 它確保您的源代碼已在確認級別上經過了全面測試。 * 使用傳統測試，成功的測試會發現一個或多個缺陷。 與 TDD 相同。 當測試失敗時，您就可以取得進步，因為您知道需要解決該問題。 * TDD 可確保您的系統實際上滿足為此定義的要求。 它有助于建立您對系統的信心。 * 在 TDD 中，更側重于驗證測試是否可以正常進行的生產代碼。 在傳統測試中，更多的重點放在測試用例設計上。 測試是否將顯示應用程序的正確/不正確執行以滿足要求。 * 在 TDD 中，您可以達到 100％的覆蓋率測試。 與傳統測試不同，每一行代碼都經過測試。 * 傳統測試與 TDD 的結合導致了測試系統而不是完善系統的重要性。 * 在敏捷建模（AM）中，您應該“有目的地進行測試”。 您應該知道為什么要測試某些東西以及需要測試什么級別。 ## 什么是接受 TDD 和開發者 TDD TDD 有兩個級別 1. **驗收 TDD（ATDD）：**使用 ATDD 編寫單個驗收測試。 該測試滿足規格要求或滿足系統性能。 之后，只需編寫足夠的生產/功能代碼即可完成該驗收測試。 驗收測試側重于系統的整體行為。 ATDD 也被稱為**行為驅動開發（BDD）。** 2. **Developer TDD:** With Developer TDD you write single developer test i.e. unit test and then just enough production code to fulfill that test. The unit test focuses on every small functionality of the system. Developer TDD is simply called as **TDD.** ATDD 和 TDD 的主要目標是在及時（JIT）的基礎上為您的解決方案指定詳細的可執行要求。 JIT 意味著僅考慮系統中需要的那些需求。 因此提高效率。  ## 通過敏捷模型驅動開發（AMDD）擴展 TDD TDD 非常擅長詳細的規范和驗證。 它無法考慮更大的問題，例如總體設計，系統使用或 UI。 AMDD 解決了 TDD 無法解決的敏捷擴展問題。 因此 AMDD 用于更大的問題。 **AMDD 的生命周期。**  在模型驅動開發（MDD）中，在編寫源代碼之前會創建大量模型。 哪個又有敏捷方法？ 在上圖中，每個框代表一個開發活動。 設想是 TDD 預測/想象測試的過程之一，它將在項目的第一周內進行。 構想的主要目標是確定系統范圍和系統體系結構。 完成高層需求和體系結構建模以實現成功的構想。 在此過程中，沒有完成軟件/系統的詳細說明，而是探索軟件/系統的需求，該需求定義了項目的整體策略。 1. **迭代 0：預想** 有兩個主要的子激活。 1. **Initial requirements envisioning.** 確定系統的高級要求和范圍可能需要幾天的時間。 主要重點是探索使用模型，初始域模型和用戶界面模型（UI）。 2. **Initial Architectural envisioning.** 識別系統的架構也需要幾天的時間。 它允許為項目設置技術指導。 主要重點是探索技術圖，用戶界面（UI）流程，域模型和變更案例。 2. **Iteration modeling:** 在這里，團隊必須計劃每次迭代要完成的工作。 * 敏捷過程用于每次迭代，即在每次迭代期間，將優先添加新的工作項。 * 首先將考慮較高優先級的工作。 添加的工作項目可以隨時重新確定優先級或從項目堆棧中刪除。 * 團隊討論了他們將如何實現每個需求。 為此使用建模。 * 對要為該迭代實現的每個需求進行建模分析和設計。 3. **Model storming:** 這也稱為即時建模。 * 在這里的建模會議中，由 2/3 的成員組成的小組討論紙質或白板上的問題。 * 一個團隊成員將要求另一個與他們建模。 建模過程大約需要 5 到 10 分鐘。 團隊成員聚集在一起共享白板/紙的地方。 * 他們會探索問題，直到找不到導致問題的主要原因。 及時地，如果一個團隊成員發現了他/她想要解決的問題，那么他/她將迅速尋求其他團隊成員的幫助。 * 然后，其他小組成員探討該問題，然后每個人都像以前一樣繼續進行。 這也稱為站立建模或客戶質量檢查會議。 4. **測試驅動開發（TDD）。** * 它促進了對您的應用程序代碼和詳細規范的確認測試。 * 接受測試（詳細要求）和開發人員測試（單元測試）都是 TDD 的輸入。 * TDD 使代碼更簡單明了。 它允許開發人員維護較少的文檔。 5. **評論。** * 這是可選的。 它包括代碼檢查和模型審查。 * 可以為每個迭代或整個項目完成。 * 這是為項目提供反饋的好選擇。 ## 測試驅動開發（TDD）與。 敏捷模型驅動開發（AMDD） | **TDD** | **AMDD** | | * TDD 縮短了編程反饋循環 | * AMDD 縮短了建模反饋循環。 | | * TDD 是詳細規格 | * AMDD 解決更大的問題 | | * TDD 促進了高質量代碼 的發展 | * AMDD 促進與利益相關者和開發人員的高質量溝通。 | | * TDD 與程序員對話 | * AMDD 與業務分析師，利益相關者和數據專業人員進行了交談。 | | * TDD 非視覺導向 | * AMDD 視覺定位 | | * TDD 僅限于軟件作品 | * AMDD 的范圍很廣，包括利益相關者。 它涉及努力達成共識 | | * 都支持進化發展 | **--------------------------------------------** | ## TDD 的示例 在此示例中，我們將定義一個類密碼。 對于本課程，我們將嘗試滿足以下條件。 密碼接受的條件： * 密碼應在 5 到 10 個字符之間。 首先，我們編寫滿足以上所有要求的代碼。  **場景 1** ：要運行測試，我們創建類 PasswordValidator（）;  我們將在類 TestPassword（）之上運行； 輸出通過，如下所示； **輸出**：  **場景 2** ：在這里我們可以在方法 TestPasswordLength（）中看到不需要創建類 PasswordValidator 的實例。 實例表示創建類的[對象](/java-oops-class-objects.html)以引用該類的成員（變量/方法）。  我們將從代碼中刪除類 PasswordValidator pv = new PasswordValidator（）。 我們可以直接通過 **PasswordValidator 調用 **isValid（）**方法。 IsValid（“ Abc123”）**。 （見下圖） 因此，我們重構（更改代碼）如下：  **場景 3** ：重構后，輸出顯示失敗狀態（請參見下圖），這是因為我們已刪除該實例。 因此，沒有引用[非靜態](/java-static-variable-methods.html)方法 **isValid（）。**  因此，我們需要通過在布爾值之前添加“靜態”字詞作為公共靜態布爾值 isValid（字符串密碼）來更改此方法。 重構類 PasswordValidator（）以消除上述錯誤，以通過測試。  **輸出：** 在對類 PassValidator（）進行更改后，如果我們運行測試，則輸出將通過，如下所示。  ## TDD 的優勢 * **Early bug notification.** 開發人員測試他們的代碼，但是在數據庫世界中，這通常包括手動測試或一次性腳本。 隨著時間的流逝，使用 TDD 可以建立一套自動化測試，您和任何其他開發人員都可以隨意重新運行。 * **更好的設計，更干凈和更可擴展的代碼。** * 它有助于了解如何使用代碼以及如何與其他模塊交互。 * 這樣可以帶來更好的設計決策和更可維護的代碼。 * TDD 允許編寫具有單一職責的較小代碼，而不是具有多個職責的整體過程。 這使代碼更易于理解。 * TDD 還強制僅編寫生產代碼以根據用戶要求通過測試。 * **重構**的信心 * 如果重構代碼，則代碼中可能會有斷點的可能性。 因此，擁有一套自動化測試，您可以在發布前修復這些漏洞。 如果在使用自動測試時發現中斷，將給出適當的警告。 * 使用 TDD 可以使代碼更快，可擴展性更高，而錯誤更少，可以以最小的風險進行更新。 * **Good for teamwork** 在沒有任何團隊成員的情況下，其他團隊成員可以輕松地接管代碼并進行工作。 它還有助于知識共享，從而使團隊整體上更有效率。 * **Good for Developers** 盡管開發人員必須花更多的時間來編寫 TDD 測試用例，但調試和開發新功能所花的時間卻少得多。 您將編寫更簡潔，更簡單的代碼。 **摘要：** * TDD 代表測試驅動的開發。 這是修改代碼以通過先前設計的測試的過程。 * 它更強調生產代碼而不是測試用例設計。 * 測試驅動的開發是修改代碼以通過先前設計的測試的過程。 * 在軟件工程中，有時稱為**“測試優先開發”。** * TDD 包括重構代碼，即在不影響代碼行為的情況下在現有代碼中更改/添加一些代碼。 * 使用 TDD 時，代碼變得更加清晰和易于理解。 本文由 **Kanchan Kulkarni** 提供