小議測試驅動開發

　在討論測試驅動開發之前，先澄清一個問題：測試驅動開發是否包括驗收測試驅動開發。測試驅動開發（Test Driven Development，簡稱TDD）存在兩種理解：

　　1、包括驗收測試驅動開發（Acceptance Test Driven Develop，簡稱ATDD）在內，這個是廣義的理解；

　　2、TDD是採用單元測試手段，主要針對非介面程式碼的，與使用者故事或需求一般沒有直接關聯，這個是狹義的理解，TDD和ATDD是並列的。多數人認為應當採用第2種理解，主要因為：

　　（1）TDD主要採用單元測試方法，典型工具有xUnit系列，ATDD主要採用介面自動化測試方法，典型工具有Selenium、QTP等；

　　（2）TDD主要用於設計和編碼，ATDD主要用於需求分析和確認。下文TDD即是採用第2種理解的TDD。

　 　在極限程式設計（Extreme Programming，簡稱XP）中TDD是與簡單設計、重構、持續整合等緊密配合的，這些組成了一套威力強大的組合裝備。TDD是其中最突出的外在表 現，XP中TDD遵循“測試驅動開發金規”：先寫一個會失敗的測試，再寫一個新特徵，永遠如此。對比在武俠世界，XP的TDD（下文稱為極限測試驅動開 發，英文為eXtreme Test Driven Development，簡稱為XTDD）屬於神器級別，功力不到者是沒法自如使用的，反而可能傷了自己。經典的單元測試方法、架構方法（比如常見的 MVC）和設計方法（包括常用的設計模式）是開展TDD的基礎，TDD的學習和 實施是循序漸進的，由簡入繁的，由淺入深的。所以把XTDD可以看成是一個極端，把沒有任何單元測試視為第二個極端，把經典軟體工程中V模型（其在單元測 試方面的特徵是針對已經有的功能程式碼編寫單元測試，以保障程式碼的質量）的完整單元測試看成第三個極端，三者組合為一個三角型，如圖一所示。從沒有任何單元 測試到XTDD，存在多種多樣的中間狀態，比如只對模組介面進行TDD，比如進行模組級的架構設計後開始TDD，比如在識別了主要類後再開始TDD，比如 對個別有把握的模組先編碼後加抽樣的單元測試，等等。在這個三角型中選擇一個合適的點，相信能夠發揮單元測試和TDD的最佳效果。在沒有足夠功力之前，先 不必開展XTDD。簡單否定TDD是不恰當的。

　　從CMMI角度看，TDD能夠滿足CMMI3級中技術方案過程域（TS）、驗證過程域（VER）和產品整合過程域（PI）的多個實踐，是不錯的工程實踐。

　　從傳統的瀑布型生命週期方法及其衍生的V模型的角度看，TDD下的基本設計比較簡略，甚至沒有，難以滿足設計里程碑評審的要求，TDD沒有詳細設計，而單元測試各項指標（比如覆蓋率、測試頻度、測試用例數量等）卻超過V模型，總體上違反了V模型。但是如果不瞭解源自於V模型下的單元測試技術、物件導向設計技術，TDD也是難以開展。

　　從XP角度看，TDD應當開展到極限。

　　從Scrum來看，TDD本身不屬於Scrum，應當由團隊來決定是否採用TDD，如果是，也由團隊來決定採用何種程度的TDD。

　　從ASD（Adaptive Software development）、FDD（Feature Driven Development）等其他敏捷方法流派來看，並沒有明確要求，根據需要來選擇開展TDD。