TDD

支持！看到这一句，基本上我就不想往下看了。

我不是说TDD方向偏了，是说觉得TDD很难用的时候，基本都是自己把问题搞复杂了。
实际情况中，小块的代码，叫class或者method都可以，都是解决简单问题的，如果觉得连unittest都很难做，那应该是把很多其他东西考虑在一起来。

另外说一下，实际情况我也不是每个项目都用TDD，只是自己必须搞好的地方才用，个人感觉TDD对程序设计要求比较高，没有经验（不是指TDD经验，而是指程序设计经验）的程序员最好有人指导。有经验的人如果搞不清楚TDD，我觉得不太可能。

看来还是我没有说清楚。
有机会和蓝皮鼠、frostred 、mock聊聊。

我很赞同，只是想补充一点，不能因噎废食。

我极度怀疑能聊明白，或者聊之前应该把kb的tdd explained里边的两个例子做一遍。


tdd不难，但是要达到楼主提到的要求，确实不是一件容易的事情，至少je中还没有看到做的很好的例子。如果有人在这方面做得很成功，并且不侵犯受保护的知识产权，希望能分享一下经验。

局外人的观点：

谈了这么多年的 TDD，怎么感觉这么多人还是在盲人摸象？每个人都看到了 TDD 的“一条腿”，然后在论坛上说“TDD 应该是这样的”，“TDD 应该是那些的”，“TDD 像棍子”，“TDD 像堵墙”，等等等等。。。。

我想问的是，既然 TDD 这玩意这么模糊、这么难以分辨，何必苦苦去“实践”？莫非各位都抱着“皇帝的新装”心态？

Tdd可以作为开发文档的一部分。

哦？怎么做？

不要一开始用自上而下的方式去推TDD，最好自下而上。03年底我花了几周的晚上业余时间把《测试驱动开发实用指南》(影印版)（jolt获奖的，当时中文版还没出）里面的例子全部手中输入并执行了一遍，感觉帮助比较大。

然后在我自己负责的项目里面，完全的按照TDD的方式来进行设计和开发，由于当时人手比较少，只是我一个人在用，所以没有什么人反对。感觉真的很爽。那个项目基本没有多花什么时间，但是效果非常好。

后来觉得开发人员最好自己严格的按照TDD的方式有过至少一次的项目开发，然后再决定开发的方式，就算以后不用TDD，但是设计和开发思路一定会受到正面影响，

另外项目中有部分关键模块采用TDD还是比较现实的，我希望大家不要顾虑太多，光说不练。还有就是从小处做起，不要搞的好象很大件事情，增加不必要的麻烦。

附图是一点证据，呵呵

蓝皮鼠 说得不错，TDD大概了解一点，但是没实践项目实践过。而且很多公司不愿用TDD,大概就是觉得它浪费时间，而且对程序员也要进行规范。