基本介紹
- 中文名：測試驅動開發
- 外文名：Test-Driven Development
- 簡寫：TDD
- 核心實踐技術：敏捷開發
以測試驅動開發,簡介,優缺點,TDD原則,
以測試驅動開發
簡介
測試驅動開發是敏捷開發中的一項核心實踐和技術，也是一種設計方法論。TDD的原理是在開發功能代碼之前，先編寫單元測試用例代碼，測試代碼確定需要編寫什麼產品代碼。TDD雖是敏捷方法的核心實踐，但不只適用於XP（Extreme Programming），同樣可以適用於其他開發方法和過程。
TDD
TDDTDD的基本思路就是通過測試來推動整個開發的進行，但測試驅動開發並不只是單純的測試工作，而是把需求分析，設計，質量控制量化的過程。
TDD的重要目的不僅僅是測試軟體，測試工作保證代碼質量僅僅是其中一部分，而且是在開發過程中幫助客戶和程式設計師去除模稜兩可的需求。TDD首先考慮使用需求（對象、功能、過程、接口等），主要是編寫測試用例框架對功能的過程和接口進行設計，而測試框架可以持續進行驗證。
優缺點
優點：在任意一個開發節點都可以拿出一個可以使用，含少量bug並具一定功能和能夠發布的產品。
缺點：增加代碼量。測試代碼是系統代碼的兩倍或更多，但是同時節省了調試程式及挑錯時間。
TDD = TFD + Refactoring
(TFD -- Test First Development)
計算機領域：
Test Drived Develop
測試驅動開發是一種開發方法，是開發人員參與的活動。 其效果是以可執行的形式文檔化你的需求，迫使你分清職責隔離依賴以驅動你的設計，編織安全網以便將Bug扼殺在在搖籃狀態，防止其逃逸。可傳統測試人員的活動是試圖找到已經逃逸的Bug。這兩種活動都是必要的，而且毫不衝突，互為補充。
那么測試人員在新的特性還沒開發完成之前做什麼呢? 除了提前寫測試用例，無論是自動化的還是非自動化的，而需要測試人員參加的一項重要活動，就是參與特性驗收條件的制定。 之前經常發生開發人員按照自己的理解去編碼，測試人員按照自己的理解去測試，直到開發完成，測試過程中才發現理解的不一致，開始產生爭執並阻塞等待業務分析人員(如果幸運的話)或者行政主管(如果開發過程混亂的話)的仲裁。 解決辦法就是，在開始開發新特性前的一剎那，由業務分析人員，測試人員，開發人員進行一次討論，就驗收條件達成一致並形成記錄，然後測試人員和開發人員分頭去寫測試和實現。
TDD原則
獨立測試：不同代碼的測試應該相互獨立，一個類對應一個測試類（對於C代碼或C++全局函式，則一個檔案對應一個測試檔案），一個函式對應一個測試函式。用例也應各自獨立，每個用例不能使用其他用例的結果數據，結果也不能依賴於用例執行順序。 一個角色：開發過程包含多種工作，如：編寫測試代碼、編寫產品代碼、代碼重構等。做不同的工作時，應專注於當前的角色，不要過多考慮其他方面的細節。
測試列表：代碼的功能點可能很多，並且需求可能是陸續出現的，任何階段想添加功能時，應把相關功能點加到測試列表中，然後才能繼續手頭工作，避免疏漏。
測試驅動：即利用測試來驅動開發，是TDD的核心。要實現某個功能，要編寫某個類或某個函式，應首先編寫測試代碼，明確這個類、這個函式如何使用，如何測試，然後在對其進行設計、編碼。
先寫斷言：編寫測試代碼時，應該首先編寫判斷代碼功能的斷言語句，然後編寫必要的輔助語句。
可測試性：產品代碼設計、開發時的應儘可能提高可測試性。每個代碼單元的功能應該比較單純，“各家自掃門前雪”，每個類、每個函式應該只做它該做的事，不要弄成大雜燴。尤其是增加新功能時，不要為了圖一時之便，隨便在原有代碼中添加功能，對於C++編程，應多考慮使用子類、繼承、重載等OO方法。
及時重構：對結構不合理，重複等“味道”不好的代碼，在測試通過後，應及時進行重構。
小步前進：軟體開發是複雜性非常高的工作，小步前進是降低複雜性的好辦法。
