測試驅動開發

測試驅動開發，是計算機程序敏捷開發中經常使用的一種方法。 在測試驅動開發中，程序員總是在要測試的組件之前創建軟件測試。

根據經典方法，例如根據瀑布或 V 模型，測試是與要測試的系統并行且獨立的，甚至是根據它開發的。 這通常意味著代碼很難測試，測試工作量很大，而且它們沒有達到預期或要求的測試覆蓋率。 可能的原因包括：

• 系統的可測試性缺失或不足。
• 禁止公司管理層對非功能性程序部分進行投資。
• 在時間壓力下或純粹為了實現所需的測試覆蓋率而創建測試。
• 程序員在創建測試時缺乏紀律。
• 白盒測試的重點是要測試的系統及其特性，以及由此產生的“繞過錯誤”測試。

測試驅動開發的方法試圖抵消白盒測試的這些缺點，同時得到更適合軟件任務和更易于維護的軟件設計。

使用測試驅動開發時，平均可以檢測或避免 45% 的錯誤。 相比之下，單獨使用單元測試時，平均只能檢測到 30% 的錯誤。

在測試驅動開發中，區分了小規模測試、模塊測試（單元測試）和大規模測試（集成測試、系統測試、驗收測試），Kent Beck 的方法是為單元測試而設計的。

單元測試是在實際的計算機程序之前編寫的。 沒有指定將執行實現的程序員是否也將創建單元測試。 允許同時存在多個失敗的單元測試。 計算機程序中單元測試所要求的行為的實現可以推遲。

測試優先方法可以看作是測試驅動開發的初級階段。

單元測試和用它們測試的單元總是并行開發的。 實際的編程是在小的、重復的微迭代中完成的。 這樣的迭代應該只需要幾分鐘，包含三個主要部分，稱為紅綠重構

• 紅色：編寫測試以檢查要編程的新行為（功能）。 你從最簡單的例子開始。 如果函數較舊，這也可能是已知錯誤或要實現的新功能。 這個測試最初沒有被現有的程序代碼完成，所以它一定會失敗。
• 綠色：盡可能少地更改程序代碼并添加到其中，直到它在隨后啟動的測試運行后通過所有測試。
• 然后清理代碼（重構）：刪除重復（代碼重復），在必要時進行抽象，使其與綁定代碼約定保持一致，等等。在這個階段，不允許有新的行為——測試不會覆蓋——待介紹。 每次更改后，都會進行測試，如果失敗，則不可能在所用代碼中采用明顯錯誤的更改。 整理的目的是讓代碼通俗易懂。

重復這三個步驟，直到已知錯誤得到糾正，代碼提供了所需的功能，并且開發人員再也想不出任何可能仍然會失敗的有意義的進一步測試。 如此處理的程序技術單元（單元）則暫時視為完成。 與她一起創建的測試將被保留，以便即使在未來發生變化后，也可以再次測試以確定已經實現的行為方面是否仍然得到滿足。

為了使步驟 2 中的更改（也稱為轉換）實現目標，每個更改都必須導致更通用的解決方案； 例如，它不能只處理當前的測試用例而犧牲其他測試用例。 越來越詳細的測試因此將代碼推向越來越通用的解決方案。 遵守 Tran形成優先級通常會導致更有效的算法。

始終遵循這種方法是一種進化設計方法，每個單獨的更改都會使系統進化。

在測試驅動開發中，系統測試總是在系統本身之前開發，或者至少是在指定之前。 在測試驅動開發的情況下，系統開發的任務不再像傳統那樣完成書面要求，而是通過指定的系統測試。

驗收測試驅動開發 (ATDD) 雖然與測試驅動開發相關，但在方法上不同于測試驅動開發。 驗收測試驅動開發是客戶或用戶、開發人員和測試人員之間的一種溝通工具，旨在確保需求得到很好的描述。 驗收測試驅動開發不需要測試用例的自動化，盡管它有助于回歸測試。 驗收測試驅動開發中的測試對于非開發人員也必須是易讀的，在很多情況下，測試驅動開發中的測試可以從驗收測試驅動開發中的測試派生出來。

除了其他目標之外，所有類型的測試驅動開發都力求盡可能完整的測試自動化。 對于測試驅動開發，所有測試都必須能夠輕松（“按下按鈕”）并盡快執行。 對于單元測試，這意味著幾秒鐘的持續時間，對于驗收或系統測試最多幾分鐘，或者僅在特殊情況下更長。

與經典方法相比，測試驅動方法的巨大優勢在于：

• 您有一個布爾指標來滿足要求：測試通過或失敗。
• 重構，即清理代碼，可以減少錯誤； 因為您是小步前進，并且始終基于通過的測試，所以幾乎不會出現新錯誤，并且更容易定位。
• 因為測試可以很容易地完成并且不需要花費很多時間，所以程序員大部分時間都在正確的系統上工作，因此有信心并專注于當前的子任務。 （沒有“穿越沙漠”，沒有“萬物相連”）
• 自動化測試記錄了系統，在驗收驅動開發的情況下，非開發人員甚至可以閱讀。 通過測試，您同時創建了一個“可執行規范”——軟件系統應該做的事情以隨時可讀和可執行的測試形式提供。
• 測試驅動的方法往往會導致程序代碼更加模塊化，并且更容易更改和擴展。 計劃的系統將分小步開發，獨立編寫和測試，然后才集成。 相應的軟件單元（類、模塊……）變得更小、更具體，它們的耦合變得更松散，它們的接口也更簡單。 如果您還使用模擬對象，這也會迫使您減少依賴性或使它們保持簡單，因為否則無法實現測試和生產代碼的基本快速和簡單的模塊交換。
• 實證研究表明，缺乏經驗的開發人員因 TDD 而導致的缺陷率較低。 然而，這也意味著花費更多的時間。 其他實證研究無法確定質量有任何提高。 總體而言，這導致僅通過 TDD 獲得的實際質量提升情況不一致。

測試驅動開發是極限編程 (XP) 和其他敏捷方法的重要組成部分。 測試驅動開發也可以在這之外找到，通常與結對編程有關。 Katas 通常用作訓練方法。