TDD與VTDD系列(三)：TDD概述

什麼是TDD
    TDD是Test-Driven Development的縮寫，即測試驅動開發。TDD的基本思路是利用測試來推進開發的進行，並非單純的測試過程。TDD是極限編程的核心之一，但TDD也能夠單獨運用。

TDD的優點
    明確需求：在軟件開發過程當中，需求經常是易變且不易描述的。項目的總體需求最終會細化爲代碼的需求，即每一個代碼單元都有其具體的功能要求。總體的需求不明確，代碼的需求天然也不能明確。即便總體需求徹底明確，細化過程也可能致使某些代碼的需求不明確。TDD首先編寫測試代碼，測試代碼其實是產品代碼的使用實例，是對產品代碼的需求描述，這個描述是明確的、無二義的、可執行的。

    明確設計：經過編寫測試代碼，對產品代碼的功能、使用方式都進行了設計，這種設計是從使用角度進行的，更符合後期開發的須要。這些設計限定了產品代碼的外延範圍，使各個代碼單元功能單純化，提升了可測試性、可維護性、可擴展性、可複用性。

    造成文檔：不少程序員不喜歡寫文檔，但閱讀、使用他人的代碼時卻要求文檔。即便是本身寫的代碼，過一段時間再閱讀、修改，沒有文檔也會很困難。測試代碼就是一種詳細文檔，記錄了代碼單元的使用方法，以及什麼輸入會產生什麼輸出。文檔是可執行、可驗證的，即便代碼頻繁更新，文檔與代碼仍然會保持一致。

    自信編程：若是缺乏測試，那麼，代碼是否正確？若是代碼須要修改，會對其餘部分形成影響嗎？測試集會保證代碼所作的，與程序員所想的一致。代碼修改後，執行迴歸測試立刻就會確認是否破壞原有功能，是否影響其餘代碼，從而更自信地工做。

    提升效率：TDD在編碼以前先編寫測試代碼，每個最小的功能點都能當即驗證是否正確，代碼錯誤可在第一時間發現和定位，大幅減小調試。若是沒有測試，編碼後的調試時間每每比編寫代碼的時間還要多得多。
強制測試：TDD要求先編寫測試代碼，再編寫產品代碼，能夠避免產品代碼寫完後，程序員的注意力轉移到其餘代碼的編寫，從而忽略測試。

TDD原則
    獨立測試：不一樣代碼的測試應該相互獨立，一個類對應一個測試類（對於C代碼或C++全局函數，則一個文件對應一個測試文件），一個函數對應一個測試函數。用例也應各自獨立，每一個用例不能使用其餘用例的結果數據，結果也不能依賴於用例執行順序。
一個角色：開發過程包含多種工做，如：編寫測試代碼、編寫產品代碼、代碼重構等。作不一樣的工做時，應專一於當前的角色，不要過多考慮其餘方面的細節。

    測試列表：代碼的功能點可能不少，而且需求多是陸續出現的，任何階段想添加功能時，應把相關功能點加到測試列表中，而後才能繼續手頭工做，避免疏漏。

    測試驅動：即利用測試來驅動開發，是TDD的核心。要實現某個功能，要編寫某個類或某個函數，應首先編寫測試代碼，明確這個類、這個函數如何使用，如何測試，而後在對其進行設計、編碼。
先寫斷言：編寫測試代碼時，應該首先編寫判斷代碼功能的斷言語句，而後編寫必要的輔助語句。

    可測試性：產品代碼設計、開發時的應儘量提升可測試性。每一個代碼單元的功能應該比較單純，「各家自掃門前雪」，每一個類、每一個函數應該只作它該作的事，不要弄成大雜燴。尤爲是增長新功能時，不要爲了圖一時之便，隨便在原有代碼中添加功能，對於C++編程，應多考慮使用子類、繼承、重載等OO方法。

    及時重構：對結構不合理，重複等「味道」很差的代碼，在測試經過後，應及時進行重構。

    小步前進：軟件開發是複雜性很是高的工做，小步前進是下降複雜性的好辦法。

TDD三條軍規    Object Meentor公司總裁，極限編程領域資深顧問Robert C. Martin提出了TDD三條軍規：    1. 除非這能讓失敗的單元測試經過，不然不容許去編寫任何的產品代碼。    2. 只容許編寫恰好可以致使失敗的單元測試（編譯失敗也屬於一種失敗）。    3. 只容許編寫恰好可以致使一個失敗的單元測試經過的產品代碼。    這三條軍規簡單明瞭地闡述了TDD過程，下一節舉例說明。