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

……
第二，事务处理是crosscuting的infrastructure，只要用AOP把它localize下来，一组测试就可以保证它的正确性，也不需要每个业务都去干这个事吧？

再说一次，TDD不是“测试”，而是设计。TDD不是用来找出错误的，而是用来描述你的设计思路的。TDD不是要替代QA的，而是要替代所谓“设计文档”的。

我明白你的意思。我也明白TDD的目的，更多的不是测试，而是用来表达设计意图。单元测试是最好的设计文档。

我不同意你的地方是：代码也是文档，它是比单元测试更加详细的设计文档；
那么，如果"单元测试文档"细到了和"代码文档"一样的水平，是不是就重复了?
我觉得mack测试的问题就是太细了，于是就引出我上面的问题和前面的另一个重构问题：
用mock测试符合TDD的直觉吗？（我在为一个组件写测试时，想得更多的是它从外面看起来是什么样子，而不会去想也还想不清楚它里面会有哪些机关）

http://forum.iteye.com/viewtopic.php?t=20035&postdays=0&postorder=asc&start=15
mock测试是如此的细致，甚至已经测试了”非可察行为“（我认为一个组件对其”助手类“进行了哪些调用、多少次调用完全是其家务事，不是可查行为）；
那么重构势必导致原有单元测试失败，重构无法进行下去，因为你已经不能保证重构没有破坏原有功能。

你完全可以忽略一些助手类。但我并不认为像“调用DAO”这种事情是“非可察行为”，它意味着你在访问数据，如果这个逻辑发生变化，它对于对象的行为是重要的。

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

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

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

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

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

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

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

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

这是没有TDD实践的人常见的误解，其实只有你实践过了，你才会明白。

那不妨谈谈你的tdd实践 很想看看tdd如何纠正这个常见"错误"  lol

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



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

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

整个顺序都反了。

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

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

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

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

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


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


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

不懂TDD啊.

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

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