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

不用再退一步了，既然你同意Rod的看法，那就按照他的来吧
至于你具体怎么用，就看你怎么想了



首先，我没有完全否定mock，我们也用，比如mock录制异常的情况就非常方便，如我前面所说


然后，想使用stub
如果你喜欢的话，可以自己写一套IoC测试套件，也不是很难
如果不喜欢自己写，可以使用spring的test包，它是可以在非Spring应用中单独使用的
但所有的前提是，你是面向接口编程的，这样你就可以轻易的使用stub，如果我没记错的话，javaeye的好多项目都省略了接口（如果记错了，就当我没说好了）springside也是，我在项目中强制使用接口。
某些情况下代码量是少于easymock的，况且很多东西可以让IDE自己来生成，只要配一下代码的模板

当然，如果你的团队已经习惯于mock，那就继续用mock吧，如同我前面所说：


最后，我很想知道，你在测DAO层时是怎么使用mock的？

easymock2.0之后，其他通用mock工具实际上已经濒临破产了，而且，通过扩展，easymock现在也能直接mock类。
我并不认同"模仿测试是透明测试"的说法，其实，模仿测试虽然透明的模仿了被mock接口的行为，但是，最重要的一点，对于使用这些mock对象的被测试方法而言，测试用例相当于规定了这些方法的实现细节(必须以合理的顺序和方式调用那些mock对象)。即便使用了Dependence Injection,这个做法也是所谓的脆弱性或者易碎性的根源，而不是模仿测试导致的。
在这种白盒测试思路下，不论用stub还是mock，都是无法避免易碎性的。

恩...charon这个论点有意思，能否详细说说？

JavaEye的开源项目没有一个是我写的，不代表我的意见。而且我看到的是JavaEye的开源项目基本上都是面向接口编程的。

我测试DAO层会启动spring容器，访问hsqldb数据库，不使用mock，具体的论述可以看这里：
http://forum.iteye.com/viewtopic.php?t=20035&start=15

stub和mock的易碎性其实还是不同的。stub对调用顺序基本没有什么依赖，而动态mock严重依赖调用顺序。所以非常复杂而频繁的逻辑调用，使用动态mock未必是一个合理的选择。

只不过我的Action里面调用Service接口，Service调用DAO接口，都是非常简单的逻辑，所以问题不大。

好了，我闪了。

这其实是单元测试究竟是一个白盒还是黑盒测试的问题(或者灰盒?)，以及测试的重用问题。以前应该讨论过一部分。
黑盒的测试用例是可重用的(对于同一个接口的不同实现而言)，白盒的测试用例是不可重用的,而且,如果被测方法内部有所调整,这个测试用例有时也必须调整(对于TFP方式,测试先行调整),实际上相当于把被测方法的一部分逻辑或者别的什么用测试用例显式确定下来了.
最后其实就是一个问题,对于一个实现某个接口的类而言,单元测试到底是在测试什么?
虽然我一直大量使用easymock,但在心里,认为唯一合法的方式,就是一个方法的副作用也正好是主要作用或唯一作用的时候. 而那种为了让一个对象的状态准备就绪而采用的脚手架方式,我有一个疑问,难道我为了测试一个业务方法是不是正确实现,还要给它提供一堆dao,还要关注这些dao是不是被以合适的顺序合适的方式调用?

springside是不强制使用接口，要用到接口在架构上的好处时还是用的，比如规则引擎的模块。
  理由说了，维护接口的成本，代码浏览跳转时老要用热键的成本，文件数量的成本，非0成本导致他真正必要用的时候，重构的时候才用，而不会一开始强制铺开。

   现在easymock都不要求基于接口了，java语言只能通过接口作proxy这点根本是不合理的，目前都在跑cglib的方案解决。 stub不用接口没法用是个问题，但早晚还是会解决的吧。

TDD是关于设计，而不是关于测试。业务逻辑需要取出x和y的数据，然后用z的方式组合这些数据，这是你的设计，所以你应该用测试来描述它。

框架本身就不支持松藕合 系统本身就没有按模块来设计 在测试上如何能划分清楚 ? 

我觉得这个不用列出一堆代码来解释. 

闪那么快干嘛 有错误可以说.

你和gigx的意思无非说人家的单元测试水平有问题 我感觉单元测试水平再高也没用 根本就不是这个问题.