2基本原理
測試驅動開發的基本思想就是在開發功能代碼之前，先編寫測試代碼，然後只編寫使測試通過的功能代碼，從而以測試來驅動整個開發過程的進行。這有助於編寫簡潔可用和高質量的代碼，有很高的靈活性和健壯性，能快速響應變化，並加速開發過程。
測試驅動開發的基本過程如下：
① 快速新增壹個測試
② 運行所有的測試（有時候只需要運行壹個或壹部分），發現新增的測試不能通過
③ 做壹些小小的改動，盡快地讓測試程序可運行，為此可以在程序中使用壹些不合情理的方法
④ 運行所有的測試，並且全部通過
⑤ 重構代碼，以消除重復設計，優化設計結構
簡單來說，就是不可運行/可運行/重構——這正是測試驅動開發的口號。
本質和優勢
或許只有了解了測試驅動開發的本質和優勢之後，妳才會領略到她的無窮魅力。 測試驅動開發不是壹種測試技術，它是壹種分析技術、設計技術，更是壹種組織所有開發活動的技術。相對於傳統的結構化開發過程方法，它具有以下優勢：[3]
1) TDD根據客戶需求編寫測試用例，對功能的過程和接口都進行了設計，而且這種從使用者角度對代碼進行的設計通常更符合後期開發的需求。因為關註用戶反饋，可以及時響應需求變更，同時因為從使用者角度出發的簡單設計，也可以更快地適應變化。
2) 出於易測試和測試獨立性的要求，將促使我們實現松耦合的設計，並更多地依賴於接口而非具體的類，提高系統的可擴展性和抗變性。而且TDD明顯地縮短了設計決策的反饋循環，使我們幾秒或幾分鐘之內就能獲得反饋。
3) 將測試工作提到編碼之前，並頻繁地運行所有測試，可以盡量地避免和盡早地發現錯誤，極大地降低了後續測試及修復的成本，提高了代碼的質量。在測試的保護下，不斷重構代碼，以消除重復設計，優化設計結構，提高了代碼的重用性，從而提高了軟件產品的質量。
4) TDD提供了持續的回歸測試，使我們擁有重構的勇氣，因為代碼的改動導致系統其他部分產生任何異常，測試都會立刻通知我們。完整的測試會幫助我們持續地跟蹤整個系統的狀態，因此我們就不需要擔心會產生什麽不可預知的副作用了。
5) TDD所產生的單元測試代碼就是最完美的開發者文檔，它們展示了所有的API該如何使用以及是如何運作的，而且它們與工作代碼保持同步，永遠是最新的。
6) TDD可以減輕壓力、降低憂慮、提高我們對代碼的信心、使我們擁有重構的勇氣，這些都是快樂工作的重要前提。
7)快速的提高了開發效率。
現狀和前景
測試驅動開發的技術已得到越來越廣泛的重視，但由於發展時間不長，相關應用並不是很成熟。現今越來越多的公司都在嘗試實踐測試驅動開發，但由於測試驅動開發對開發人員要求比較高，更與開發人員的傳統思維習慣相違背，因此實踐起來有壹定困難。 美國不少著名軟件公司如IBM很早就開始向敏捷轉型，在此過程中，TDD通常是最重要也最艱難的壹個，正如IBM開發轉型部門副總裁Sue Mckinney所言：測試驅動開發前景非常誘人，但是“在這個過程中我們的付出可能也是最多的。”Forrester的高級分析師Dave West認為，測試驅動開發（TDD）就像是“聖杯”，但是“如果能達到這個目標，付出再多的辛苦也是值得的。”
我想，測試驅動開發的推廣過程中，首要的問題是將開發人員長期以來形成的思維觀念和意識形態轉變過來，開發人員只喜歡編碼，不喜歡測試，更無法理解為什麽沒有產品代碼的時候就先寫單元測試；其次是相關的技術支持，測試驅動開發對開發人員提出了更高的要求，不僅要掌握測試和重構，還要懂得設計模式等設計方面的知識。
正像每種革命性的產物剛剛產生之初所必然要經歷的艱難歷程，測試驅動開發也正在經歷著，但她正在逐漸走向成熟，前途壹片光明。相信未來幾年內，國內的壹定會越來越多的軟件企業開始普及測試驅動開發。