TDD

測試驅動開發是敏捷開發中的一項核心實踐和技術。

TDD的基本思路就是通過測試來推動整個開發的進行，但測試驅動開發並不只是單純的測試工作，而是把需求分析，設計，質量控制量化的過程。

TDD的重要目的不僅僅是測試軟體，測試工作保證代碼質量僅僅是其中一部分，而且是在開發過程中幫助客戶和程序員去除模稜兩可的需求。TDD首先考慮使用需求（對象、功能、過程、介面等），主要是編寫測試用例框架對功能的過程和介面進行設計，而測試框架可以持續進行驗證。

優點：在任意一個開發節點都可以拿出一個可以使用，含少量bug並具一定功能和能夠發布的產品。

缺點：增加代碼量。測試代碼是系統代碼的兩倍或更多，但是同時節省了調試程序及挑錯時間。

TDD = TFD + Refactoring

(TFD -- Test First Development)

計算機領域：

Test Drived Develop

測試驅動開發是一種開發方法，是開發人員參與的活動。其效果是以可執行的形式文檔化你的需求，迫使你分清職責隔離依賴以驅動你的設計，編織安全網以便將Bug扼殺在在搖籃狀態，防止其逃逸。可傳統測試人員的活動是試圖找到已經逃逸的Bug。這兩種活動都是必要的，而且毫不衝突，互為補充。

那麼測試人員在新的特性還沒開發完成之前做什麼呢? 除了提前寫測試用例，無論是自動化的還是非自動化的，而需要測試人員參加的一項重要活動，就是參與特性驗收條件的制定。之前經常發生開發人員按照自己的理解去編碼，測試人員按照自己的理解去測試，直到開發完成，測試過程中才發現理解的不一致，開始產生爭執並阻塞等待業務分析人員(如果幸運的話)或者行政主管(如果開發過程混亂的話)的仲裁。解決辦法就是，在開始開發新特性前的一剎那，由業務分析人員，測試人員，開發人員進行一次討論，就驗收條件達成一致並形成記錄，然後測試人員和開發人員分頭去寫測試和實現。

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

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

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

先徠寫斷言：編寫測試代碼時，應該首先編寫判斷代碼功能的斷言語句，然後編寫必要的輔助語句。

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

及時重構：對結構不合理，重複等“味道”不好的代碼，在測試通過後，應及時進行重構。

小步前進：軟體開發是複雜性非常高的工作，小步前進是降低複雜性的好辦法。