在討論測試驅動開發之前，先澄清一個問題：測試驅動開發是否包括驗收測試驅動開發。測試驅動開發（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。