TDD[測試驅動開發(Test-Driven Development)]

TDD[測試驅動開發(Test-Driven Development)]

TDD是測試驅動開發(Test-Driven Development)的英文簡稱,是敏捷開發中的一項核心實踐和技術,也是一種設計方法論。TDD的原理是在開發功能代碼之前,先編寫單元測試用例代碼,測試代碼確定需要編寫什麼產品代碼。TDD雖是敏捷方法的核心實踐,但不只適用於XP(Extreme Programming),同樣可以適用於其他開發方法和過程。

以測試驅動開發

簡介

TDD TDD

測試驅動開發是敏捷開發中的一項核心實踐和技術,也是一種設計方法論。TDD的原理是在開發功能代碼之前,先編寫單元測試用例代碼,測試代碼確定需要編寫什麼產品代碼。TDD雖是敏捷方法的核心實踐,但不只適用於XP(Extreme Programming),同樣可以適用於其他開發方法和過程。

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

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

優缺點

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

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

TDD = TFD + Refactoring

(TFD -- Test First Development)

計算機領域:

Test Drived Develop

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

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

TDD原則

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

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

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

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

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

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

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

熱門詞條

聯絡我們