ok，TDD只是一个coder的工具!

TDD热度在上升，我这里给它降降温
    ——" TDD只是一个coder的工具!"

不得不承认，TDD是一种比较一石二鸟的思想，将需求与测试统一，即能严格满足需求，又能对实现进行测试。可是，在能TDD之前，和TDD之后，还有太多的事情要做....

通常，一个开发周期至少要包括:分析，设计，编码，测试4个步骤，其中，分析和设计阶段将会占用一个项目中的大部分时间（这里我不想讨论毫无技术含量的重复开发），可是在分析和设计阶段，tdd基本是毫无用处的。tdd只有在设计的后期，基本完成至少精确到接口的设计后，才能依赖于设计进行测试驱动的编码。而且，作为设计人员，是很难在这个阶段进行测试驱动编码工作，因为没有人能保证第一次设计的粒度能直接精确到可以编写测试驱动的地步（你说你能保证？ok,地球太危险，您还是回到火星去吧...）。最后，测试驱动就只能由进行实现的coder编写。。

在coder们惊叹tdd在数十次迭代后居然给他节省了那么多时间的时候（或者很后悔在一个十分简单的项目里用了tdd的时候），很不幸，真正的测试要开始了。（如果你还认为tdd后不再需要测试的话，您最好期待您的客户都是冤大头）

对于测试最正确的方法，是从需求开始，这个阶段需要回顾需求（如果有专门的测试部门的话，这个阶段会和开发部门的需求分析一起开始。），根据需求写出测试用例，根据测试用例写出测试代码或者手动进行测试。在这个阶段，测试驱动的代码能用么？当然是不行的，测试人员必须验证项目是否直接符合需求。如果你想说tdd代码就代表了需求，那么谁来保证你的tdd代码就真正能代表需求？软件测试不是要测试你的代码质量，而是要保证项目质量！

在掐头去尾以后，tdd能够服务于项目的时间只剩下了code阶段。可惜，在这个阶段，无论是测试驱动code,还是code完再写测试，已经没有本质的区别了（你要硬说有区别，那也只是先有鸡和先有蛋的区别，没什么值得讨论的。），换句话来说，你是想用tdd还是做好单元测试，都是随你的意，喜欢哪种就用哪种。

最后加上一句：没有最好的方法，只有最好的人！