极限编程时是软件开发中拥抱变化的产物。

测试驱动开发（Test-driven development）是极限编程中倡导的程序开发方法，以其倡导先写测试程序，然后编码实现其功能得名。测试驱动开发始于20世纪90年代。测试驱动开发。测试驱动开发的目的是取得快速反馈并使用“illustrate the main line”方法来构建程序。

测试驱动开发是戴两顶帽子思考的开发方式：先戴上实现功能的帽子，在测试的辅助下，快速实现其功能；再戴上重构的帽子，在测试的保护下，通过去除冗余的代码，提高代码质量。测试驱动着整个开发过程：首先，驱动代码的设计和功能的实现；其后，驱动代码的再设计和重构。

测试驱动开发中测试的特征[编辑]

测试驱动开发中需求分析和详细设计的范畴，在代码基本完毕以后，并且这些测试也成为单元测试的一个部分。

应用领域[ 新软件的开发，历史系统的维护。

测试驱动开发相关讨论[]

正面评价[]

• 可以有效的避免过度设计带来的浪费。但是也有人强调在开发前需要有完整的设计再实施可以有效的避免重构带来的浪费。
@H_502_30@
• 可以让开发者在开发中拥有更全面的视角。
@H_502_30@

负面评价[

开发者可能只完成满足了测试的代码，而忽略了对实际需求的实现。有实践者认为用结对编程的方式可以有效的避免这个问题。

@H_502_30@

• 会放慢开发实际代码的速度，特别对于要求开发速度的原型开发造成不利。这里需要考虑开发速度需要包含功能和品质两个方面，单纯的代码速度可能不能完全代表开发速度。
@H_502_30@
• 对于GUI,资料库和Web应用而言。构造单元测试比较困难，如果强行构造单元测试，反而给维护带来额外的工作量。有开发者认为这个是由于设计方法，而不是开发方法造成的困难。
@H_502_30@
• 使得开发更为关注用例和测试案例，而不是设计本身。目前，对于这个观点有较多的争议。
@H_502_30@
• 测试驱动开发会导致单元测试的覆盖度不够，比如可能缺乏边界测试。在实际的操作中，和非测试驱动开发一样，当代码完成以后还是需要补充单元测试，提高测试的覆盖度。
@H_502_30@