什么是“测试驱动开发”

看来也要加入反对极限编程的阵营了，喜欢敏捷编程，喜欢Pragmatic编程，喜欢微软的秘密，就是不喜欢这极限编程。

这样下去不是和CMM5一个样，不事生产的老爷们把程序员当猴耍么。

一个method一个职责是必要的
但是一个类一个职责，有时候要求会变得很高。
就像firebody的那个例子，如果是私有方法，而且是只有被这个类用到的私有方法，从KISS原则上来说，是不应当分离出一个接口的。如果要用到策略模式或者别的，也是在发现有多个实现的时候才浮现的，这个本来就是TDD的一个好处。因为你的测试保证了即便在将来分离出一个接口，你仍然可以用足够安全的方式来做这件事情。这个是所谓的设计弹性所在。如果不停的分离接口/实现类，最后会出现一个很深的结构层次，对于理解绝对是个考验。
那么，这样的私有方法怎么测试。在不分离的前提下，就只能牺牲封装性了，把private的搞成protected。这样做合不合适不知道，反正我就经常这么搞。
为了便于测试而搞出一些东西来，从某种意义上说，已经在违反其他原则了。怎么取得均衡，那是高手才能做的。

呵呵，你看，沉不住气了不是。
讨论TDD的理解 又不是挥着大棒子来讨伐XP，我一直都是XP的拥护者，同时也是追随者。
每个method不超过5行，那是一个玩笑话。 真的不可能。

只不过就着上面我得代码来看，抽取method到接口在很多时候确实是一个重构趋势。 现在就着这个结果来看，TDD又何尝不是先行一步呢？

说得很有意思，讨论如此深入下去吧。
呵呵，如果需要针对这个私有方法做测试，首先需要一定就是需要测试这个方法所改变的参数对象的状态。
为了需要测试private doSomeLogicInternal私有方法的改变对象状态的逻辑，这里又几个可行的方安：

1） 用IArgumentMatcher 来作。
伪代码如下:

reportMatcher(new IArgumentMatcher();{

			public boolean matches(Object arg0); {
				Bean b = (Bean); arg0;
//判断此时对象的被改变的状态 
//返回 true 或者 false				
			}

			public void appendTo(StringBuffer arg0); {
			}});;

2）将私有方法改成protected，单独测试

3)抽出一个接口，单独测试
我个人会选择第一种方安。

不过这样一来，就有另外一个问题。
一个类里面不应当包括任何notrivial的私有方法，因为这个非常难以单独测试。
是不是应当有一个TDD下私有方法是evil的说法？

是每个method不超过3行，而且似乎不是玩笑，是先进经验介绍。

"大家比较反感的就是接口/类的繁多。 "

大家对类/接口和包有什么好的命名规范？
现在只是基于当前需求的一种测试替换。但当需求变了 业务逻辑出现变化 这样怎么快速的找到需要修改的类。
象webwork 有个东东需要改 先看xwork.xml定义 找到action 然后service直到dao。
所以类/接口多了 怎么做到比较好的找到想改的东东？
不知道大家是怎么做的？
还有在tdd中这时是不是要先改对应的测试类的代码？

没必要这样的，我前面说得太草率了，其实要测试doSomeLogicInternal的逻辑，没必要分离接口或者protected 才能测试的，matcher测试是完全可以的。
比如这样:

reportMatcher(new IArgumentMatcher();{

			public boolean matches(Object arg0); {
				Bean b = (Bean); arg0;
           //判断所改变的对象的状态
				return ...//
			}

			public void appendTo(StringBuffer arg0); {
			}});;

这个设定就是作为doSomeLogicInternal的一个契约说明在测试代码中得到反映，我前面说得必须分离接口才能很好的测试有点过于草率了。

钻你的牛角尖去吧。 呵呵，使劲钻。 我不会打扰你的。   

:) 在BJUG里面有原话的哦。



飘过飘过，你们继续务实地讨论：）