在讨论测试驱动开发之前，先澄清一个问题：测试驱动开发是否包括验收测试驱动开发。测试驱动开发（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。