基本介紹
基本介紹,基本原理,測試驅動開發中測試的特徵,生動釋義,本質優勢,現狀前景,測試驅動開發相關討論,正面評價,負面評價,
基本介紹
Kent Beck先生最早在其極限編程（XP）方法論中，向大家推薦“測試驅動”這一最佳實踐，還專門撰寫了《測試驅動開發》一書，詳細說明如何實現。經過幾年的迅猛發展，測試驅動開發已經成長為一門獨立的軟體開發技術，其名氣甚至蓋過了極限編程。
套用領域：新軟體的開發，歷史系統的維護。
基本原理
測試驅動開發的基本思想就是在開發功能代碼之前，先編寫測試代碼，然後只編寫使測試通過的功能代碼，從而以測試來驅動整個開發過程的進行。這有助於編寫簡潔可用和高質量的代碼，有很高的靈活性和健壯性，能快速回響變化，並加速開發過程。
測試驅動開發的基本過程如下：
① 快速新增一個測試
② 運行所有的測試（有時候只需要運行一個或一部分），發現新增的測試不能通過
③ 做一些小小的改動，儘快地讓測試程式可運行，為此可以在程式中使用一些不合情理的方法
④ 運行所有的測試，並且全部通過
⑤ 重構代碼，以消除重複設計，最佳化設計結構
簡單來說，就是不可運行/可運行/重構——這正是測試驅動開發的口號。
測試驅動開發中測試的特徵
測試驅動開發中需求分析和詳細設計的範疇，在代碼基本完畢以後，並且這些測試也成為單元測試的一個部分。
生動釋義
舉個比較生動的例子，這個例子你一定已經在很多關於TDD的文獻資料上都看到過，但它確實是一個不錯的比喻。在此我進行了一些加工和擴展。
蓋房子的時候，工人師傅砌牆，會先用樁子拉上線，以使磚能夠壘的筆直，因為壘磚的時候都是以這根線為基準的。TDD就像這樣，先寫測試代碼，就像工人師傅先用樁子拉上線，然後編碼的時候以此為基準，只編寫符合這個測試的功能代碼。
而一個新手或菜鳥級的小師傅，卻可能不知道拉線，而是直接把磚往上壘，壘了一些之後再看是否筆直，這時候可能會用一根線，量一下砌好的牆是否筆直，如果不直再進行校正，敲敲打打。使用傳統的軟體開發過程就像這樣，我們先編碼，編碼完成之後才寫測試程式，以此檢驗已寫的代碼是否正確，如果有錯誤再一點點修改。
你是希望先砌牆再拉線，還是希望先拉線再砌牆呢？如果你喜歡前者，那就算了，而如果你喜歡後者，那就轉入TDD陣營吧！詳細可參閱。
本質優勢
或許只有了解了測試驅動開發的本質和優勢之後，你才會領略到她的無窮魅力。 測試驅動開發不是一種測試技術，它是一種分析技術、設計技術，更是一種組織所有開發活動的技術。相對於傳統的結構化開發過程方法，它具有以下優勢：
1) TDD根據客戶需求編寫測試用例，對功能的過程和接口都進行了設計，而且這種從使用者角度對代碼進行的設計通常更符合後期開發的需求。因為關注用戶反饋，可以及時回響需求變更，同時因為從使用者角度出發的簡單設計，也可以更快地適應變化。
2) 出於易測試和測試獨立性的要求，將促使我們實現松耦合的設計，並更多地依賴於接口而非具體的類，提高系統的可擴展性和抗變性。而且TDD明顯地縮短了設計決策的反饋循環，使我們幾秒或幾分鐘之內就能獲得反饋。
3) 將測試工作提到編碼之前，並頻繁地運行所有測試，可以儘量地避免和儘早地發現錯誤，極大地降低了後續測試及修復的成本，提高了代碼的質量。在測試的保護下，不斷重構代碼，以消除重複設計，最佳化設計結構，提高了代碼的重用性，從而提高了軟體產品的質量。
4) TDD提供了持續的回歸測試，使我們擁有重構的勇氣，因為代碼的改動導致系統其他部分產生任何異常，測試都會立刻通知我們。完整的測試會幫助我們持續地跟蹤整個系統的狀態，因此我們就不需要擔心會產生什麼不可預知的副作用了。
5) TDD所產生的單元測試代碼就是最比較好的開發者文檔，它們展示了所有的API該如何使用以及是如何運作的，而且它們與工作代碼保持同步，永遠是最新的。
6) TDD可以減輕壓力、降低憂慮、提高我們對代碼的信心、使我們擁有重構的勇氣，這些都是快樂工作的重要前提。
7)快速的提高了開發效率。
現狀前景
測試驅動開發的技術已得到越來越廣泛的重視，但由於發展時間不長，相關套用並不是很成熟。現今越來越多的公司都在嘗試實踐測試驅動開發，但由於測試驅動開發對開發人員要求比較高，更與開發人員的傳統思維習慣相違背，因此實踐起來有一定困難。 美國不少著名軟體公司如IBM很早就開始向敏捷轉型，在此過程中，TDD通常是最重要也最艱難的一個，正如IBM開發轉型部門副總裁Sue Mckinney所言：測試驅動開發前景非常誘人，但是“在這個過程中我們的付出可能也是最多的。”Forrester的高級分析師Dave West認為，測試驅動開發（TDD）就像是“聖杯”，但是“如果能達到這個目標，付出再多的辛苦也是值得的。”
我想，測試驅動開發的推廣過程中，首要的問題是將開發人員長期以來形成的思維觀念和意識形態轉變過來，開發人員只喜歡編碼，不喜歡測試，更無法理解為什麼沒有產品代碼的時候就先寫單元測試；其次是相關的技術支持，測試驅動開發對開發人員提出了更高的要求，不僅要掌握測試和重構，還要懂得設計模式等設計方面的知識。
正像每種革命性的產物剛剛產生之初所必然要經歷的艱難歷程，測試驅動開發也正在經歷著，但她正在逐漸走向成熟，前途一片光明。相信未來幾年內，國內的一定會越來越多的軟體企業開始普及測試驅動開發。
測試驅動開發相關討論
正面評價
- 可以有效的避免過度設計帶來的浪費。但是也有人強調在開發前需要有完整的設計再實施可以有效的避免重構帶來的浪費。
- 可以讓開發者在開發中擁有更全面的視角。
負面評價
- 開發者可能只完成滿足了測試的代碼，而忽略了對實際需求的實現。有實踐者認為用結對編程的方式可以有效的避免這個問題。
- 會放慢開發實際代碼的速度，特別對於要求開發速度的原型開發造成不利。這裡需要考慮開發速度需要包含功能和品質兩個方面，單純的代碼速度可能不能完全代表開發速度。
- 對於GUI,資料庫和Web套用而言。構造單元測試比較困難，如果強行構造單元測試，反而給維護帶來額外的工作量。有開發者認為這個是由於設計方法，而不是開發方法造成的困難。
- 使得開發更為關注用例和測試案例，而不是設計本身。當前對於這個觀點有較多的爭議。
- 測試驅動開發會導致單元測試的覆蓋度不夠，比如可能缺乏邊界測試。在實際的操作中，和非測試驅動開發一樣，當代碼完成以後還是需要補充單元測試，提高測試的覆蓋度。
