測試驅動開發

出自 MBA智库百科(https://wiki.mbalib.com/)

測試驅動開發（Test-Driven Development）

　　測試驅動開發，英文全稱Test-Driven Development，簡稱TDD，是一種不同於傳統軟體開發流程的新型的開發方法。它要求在編寫某個功能的代碼之前先編寫測試代碼，然後只編寫使測試通過的功能代碼，通過測試來推動整個開發的進行。這有助於編寫簡潔可用和高質量的代碼，並加速開發過程。

　　TDD將測試方案設計工作提前，在編寫代碼之前先做：從測試的角度來驗證設計，推導設計；同時將測試方案當作行為的準繩，有效地利用其檢驗代碼編寫的每一步，實時驗證其正確性。如此迴圈迭代，實現開發過程的“小步快走”。

　　TDD是一種分析方法。在TDD中，需求將完全表述為測試代碼。這樣，軟體設計師的需求工作就不再是編寫用例規約來覆蓋用戶的需要，而是迫使仔細思考要做什麼和不做什麼。特別是各種例外的情況，並用程式語言正式的寫下來，即編寫測試代碼來捕獲用戶的需要。將需求整理為測試代碼的形式。只要代碼只要能夠通過測試，就代表該代碼設計已經能夠滿足客戶需求。當然，這種肯定是有前提的。即測試代碼能夠完整的、精確的描述需求。另外，因為從使用者的角度寫出測試代碼。除要關心程式功能的本身外，還要對介面予以足夠關註。便於更進一步明確需求。

　　TDD是一種設計方法。它用測試推進設計。必須清晰的定義程式的界面才能寫出測試用例，通過編寫測試用例，對其功能分解、使用過程、介面都要進行了設計。而且，這種從易用性的視角的代碼設計，通常更符合後期開發的需求可測試的要求。對代碼的內聚性的提高和復用都非常有益。這樣的需求總是完整的被體現在了各個模塊的介面上。即。保證對介面的使用能夠正確無誤的進行，就保證了這個模塊的最終質量。

　　TDD是一種質量控制方法。開發者在項目的壓力下往往忽略測試，而沒有測試的軟體增加了開發者的壓力，TDD有一套完整的單元測試作為回歸測試。保證現在能工作的代碼將來也能工作，也可作為集成測試的檢查點。TDD不是通常意義上的測試技術，它的目的也不是僅僅用來測試你的代碼。TDD是把需求分析。設計，質量控制量化的過程!

　　TDD是一種重構和優化的方法。程式員總希望代碼質量高，所以會不斷地去改進，TDD確保改進和優化後的質量TDD是一種面向對象的開發方法。程式員必須清晰地定義程式的界面和功能才能寫出單元測試用例，而不必關心邏輯是如何實現。

　　TDD是文檔。TDD是通過寫測試來寫代碼，當用這個視角去實踐TDD時，測試用例會細化到以什麼條件和參數、調用什麼方法及會有什麼返回值等，這就是文檔，產生的測試用例代碼就是對代碼的最好的解釋。說明瞭代碼的運行機制，而且這種程式自我編檔的方式也促進了交流和反饋。

　　TDD提供的測試集是信心的來源。快樂工作的基礎就是對自己有信心。對自己的工作成果有信心：不用擔心代碼是否正確、還有沒有嚴重bug、修改對其他部分有沒有影響。

　　測試驅動開發的基本思想就是在開發功能代碼之前，先編寫測試代碼，然後只編寫使測試通過的功能代碼，從而以測試來驅動整個開發過程的進行。這有助於編寫簡潔可用和高質量的代碼，有很高的靈活性和健壯性，能快速響應變化，並加速開發過程。測試驅動開發的基本過程如下：

　　①快速新增一個測試

　　②運行所有的測試（有時候只需要運行一個或一部分），發現新增的測試不能通過

　　③做一些小小的改動，儘快地讓測試程式可運行，為此可以在程式中使用一些不合情理的方法

　　④運行所有的測試，並且全部通過

　　⑤重構代碼，以消除重覆設計，優化設計結構

　　簡單來說，就是不可運行/可運行/重構——這正是測試驅動開發的口號。

　　測試驅動開發不是一種測試技術，它是一種分析技術、設計技術，更是一種組織所有開發活動的技術。相對於傳統的結構化開發過程方法，它具有以下優勢：

　　1)TDD根據客戶需求編寫測試用例，對功能的過程和介面都進行了設計，而且這種從使用者角度對代碼進行的設計通常更符合後期開發的需求。因為關註用戶反饋，可以及時響應需求變更，同時因為從使用者角度出發的簡單設計，也可以更快地適應變化。

　　2)出於易測試和測試獨立性的要求，將促使我們實現松耦合的設計，並更多地依賴於介面而非具體的類，提高系統的可擴展性和抗變性。而且TDD明顯地縮短了設計決策的反饋迴圈，使我們幾秒或幾分鐘之內就能獲得反饋。

　　3)將測試工作提到編碼之前，並頻繁地運行所有測試，可以儘量地避免和儘早地發現錯誤，極大地降低了後續測試及修複的成本，提高了代碼的質量。在測試的保護下，不斷重構代碼，以消除重覆設計，優化設計結構，提高了代碼的重用性，從而提高了軟體產品的質量。

　　4)TDD提供了持續的回歸測試，使我們擁有重構的勇氣，因為代碼的改動導致系統其他部分產生任何異常，測試都會立刻通知我們。完整的測試會幫助我們持續地跟蹤整個系統的狀態，因此我們就不需要擔心會產生什麼不可預知的副作用了。

　　5)TDD所產生的單元測試代碼就是最完美的開發者文檔，它們展示了所有的API該如何使用以及是如何運作的，而且它們與工作代碼保持同步，永遠是最新的。

　　6)TDD可以減輕壓力、降低憂慮、提高我們對代碼的信心、使我們擁有重構的勇氣，這些都是快樂工作的重要前提。

　　7)快速的提高了開發效率。

　　TDD實質是一種編程技術．它間接地確保代碼能徹底地被單元測試檢查。但仍然需要參考傳統的一些測試比如功能測試、用戶驗收測試、系統集成測試等等。一個好的傳統測試能發現一個或多個漏洞。此理論同樣適用於TDD。當一個測試失敗時就必須進行改進，因為需要解決這個問題。更重要的是，當測試不再失敗時．就可以清楚地知道成功了多少。TDD增強了信心因為它適應了預先定下的需求。

　　像傳統的測試一樣，項目風險越大，就要更徹底地進行測試，儘可能測試一切可以測試的東西『61。傳統測試和TDD中都不可能為著完美而奮鬥，代之的是測試系統的重要性，應該帶著目的去測試、知道為什麼要測試以及測試是在什麼等級。TDD的代碼測試覆蓋率是100％．這是傳統測試所不能保證的。

　　如果為一個功能值得寫代碼，那麼一定值得測試。如果不值得測試．那又何必浪費時間去寫一些無用的代碼呢?TDD不能替代傳統的測試，相反它定義一種驗證方式來確保單元測試的有效性。