在上面的图中，列出的的是XP的12个团队实践。Test-Driven Development是其中之一。
Kent Beck 的著作TDD(Test Driven Development) 中详细讲述了测试驱动开发。
在XP中测试是一种设计，不是简单的为了测试你的功能是否实现。测试先行一个目的
是可以在代码编写之前，保证测试已经写好；其实这些测试的另一个目的就是设计接口，
保证接口在以后的修改过程中能够满足测试（设计）。当你有意或无意修改接口的时候，你必须同时
修改测试 要改动接口的时候，也应该是先修改测试，再修改代码。而不是修改代码等着报错再修改
测试(设计）。（测试必须100%通过才能进行下一个功能），这样测试也是在提醒你，接口已经改变。
实际上，设计已经改变。当你修改单元测试的时候，可能就会遭到抱怨。为什么？你修改了设计
，别人的代码是依赖你修改前的测试（设计），那么新的测试（设计）中的变动可能要影响到
别人已有的代码。
当你使用TDD的时候一定要说明是测试驱动开发还是测试驱动设计。这两者是有区别的。测试驱动
开发，是通过测试定义所要开发的功能的接口，然后实现功能的开发过程。对于测试驱动设计，在XP中似乎
已经消失了，而是被测试驱动开发所取代。另外在XP中有用于描述设计的，SimpleDesign ，Design Improvement.
在XP中测试是一种设计，设计之后才有开发，这也就是为什么要测试先行了。
在XP中测试是一种文档，用于描述设计。
-------------------------------------------------------------------------------------------------------
UNIT TEST又叫单元测试，是针对程序最基本结构单元所进行的测试。而TDD的过程是这样的，写一个测试程序，使其可以运行，重构。在写这个测试程序的时候你考虑的不应该是基于什么结构单元，而是要考虑需要完成的什么功能。实现和重构的时候，具体是不是这个单元完成了这个功能依然不是你应该去考虑的，你考虑的还是——是不是完成了这个功能、是不是代码真的清晰和可工作。你考虑的问题永远是围绕着具体的功能进行的，而不是围绕某种结构进行的。你写这个测试程序的时候，这个结构并不存在，并且今后也可能不存在（由于重构，你在别的结构部分实现了这个功能）。
明白这个道理就可以明白TDD实际还是基于需求驱动的，还是一种前瞻性的设计手段。只不过TDD让这个需求更加具体，让其前瞻性也更可以预测，并且在多种方法中给了你进行多种尝试的机会。而当你认为这个测试只是单元测试的时候，无疑你就把程序的结构早早的做了一个固定，其是基于结构的而不是基于需求的，并且由于其基于结构的一面则设计的前瞻性很难得到保证，而就根本性的断绝了你进行多种尝试的可能。设计的前瞻性是指你的设计可以带来可以预测的结果。而软件的结构是动态的，并且随着你必须进行的重构活动这样的结构变更会日常性的存在。如果你的一个测试高度的依靠某种特殊的结构，在这样的经常性重构的环境下，其被经常性修改的几率会大大增加。而由于其结构的不确定性是根本不可能逆转的，所以针对结构进行的测试根本不可能带来结构上的可预测性，而谈不上什么前瞻性了。
<<
这段话对TDD作了清澈的分析，TDD不单纯是以测试来驱动代码的编写。
我们还没有实践TDD，不是每个成员都对TDD很认同，并且了解怎么来做，这包括我。但是有一点需要强调——TDD不单纯是以测试来驱动代码的编写，而是对整个开发流程的驱动。
