吹弹得破是重回一人犯错，全家光荣的老路

整个顺序都反了。

你测试的东西所牵连的部分越多，出现错误时，需要查找的内容也就越多，范围也就越大。

假设一个系统有100个单元， 你在应用测试时发生错误，那么你就可能需要在这一百个单元内查找。（最坏情况）
或者是，你改了单元A，单元B 又出问题，最终发现单元C才是罪魁祸首。

但是你单元测试，出现错误，只需要在这个单元里查找。

单元测试首先减少的是小单位代码的错误率，这样才能整体减少debug时间。
套用别人的一句话， 航天飞机要保证每个元件的99.99%的正确度，才能让整体有大概90%的正确度。
就是说，单元的错误率在集成后，会放大到整体。

所以一般都是单元测试放到最前面。


我觉得winterwolf问题应该是说当对一个系统仅仅有一个概念上的想法时怎样才能以TDD启动开发，因为很多细节问题都还没有解决。
我也有这个问题，如果想要比较快的话，感觉还是要有有经验的人，先进行分层，模块划分，之后再做。如果只考虑上层的话，确实有点空中楼阁的感觉。


?  啊哦，贴晚了点，算是给robbin的补充吧。

通过经验的积累 和小的窍门自然可以提高工作效率 但是要做到质变必须采用新的技术. 其实楼主的问题我已经基本解决了.

其实这些误解在XP的经典教材里面都有详细的解释阿，请看《解析极限编程》和《规划极限编程》。我想我就不用赘述了。

写代码之前，我心里会有一个大致的系统架构设想，这来自于经验的积累，其实XP也很强调这一点。然后才会开始编写代码。

另外即使你不TDD，你也一样会经常调整架构，没有人可以在做任何事情之前就把一切都想的很好。但是TDD可以保证你在调整架构的时候，保持代码的新鲜程度，而不是越改越腐烂。

从这个论坛了解的敏捷就是很普通的编程方式, 凡是要干活的就自然是这么做的. 敏捷只是编程实践的一些总结 并没有什么大的创新 也没有做出实用的框架或者标准. 

呵呵，被框架和标准毒害的。

开个玩笑。 某种意义上敏捷开发是 好的程序员追求美的代码，美的代码提供更好的开发效率 的概念实践。

有框架和标准才能有合适的开发工具和组件 没有铁轨就开不了车. 当然喜欢步行除外

我想很多人可能会反对我的观点

我认为对所有代码都做单元测试本身就是一个错误 从理论上讲没有绝对完美的代码.

测试的关键是要极早发现关键问题 那么测试的顺序就应该是

1 应用测试
2 单相功能的性能测试
3 单元测试

如果先开始做单元测试就如同管中窥豹 会犯一些捡芝麻丢西瓜的错误.
而且到最后系统做大的调整 这样的测试恐怕也没时间做了.

如果认同我的观点 那么再看看现有的框架 是否能组件化到可以脱离整个系统先做应用测试.

从自己的经验出发 我感觉无论如何也做不到. 除非 web框架本身就是为此目的设计的. 接口粗放到组件可以不考虑整个系统而先做开发 先做测试的水平.

我认为只有实现这一步才算真正的敏捷

有框架和标准才能有合适的开发工具和组件 没有铁轨就开不了车. 当然喜欢步行除外