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

还是两码事，看来你还没有用过easymock。

猜错

如果你用过了easymock，还这样想，那就有点遗憾了。

如果你用过easymock和spring的mock包之后还不明白我说的，那才真的遗憾
why mock？think about it。所谓异曲同工正是出于这点
easymock这种方式的问题在于
测试的操作越复杂，mock的成本就越高
并且它是完全透明的测试，会是测试变得脆弱

spring mock包仅仅包括Servlet API的mock对象和JNDI的mock对象而已。而easymock是一个可以对任意Interface和Class进行mock的动态Mock库。我看不出这两者有什么异曲同工之处。

其实正是因为easymock是完全透明的测试，它仅仅强调接口的契约，而接口后面怎么实现完全不管，所以才能做到良好的单元测试和接口的隔离性，这正是我非常喜欢用easymock的原因之一，只有做到了这一点，才能保证团队开发互相之间仅仅依靠接口契约，而互相不会影响。至于所谓什么是测试变得脆弱那是无稽之谈，单元测试不对接口以外的东西负责，这是集成测试的责任。

spring有60%的test用的是easymock，看来你真的应该好好建议Rod Johnson改用你提倡的stub，废掉easymock了。

以上建议正是来自于rod
也许你该好好的，仔细的看看或分析一下rod写的东西

我没有看明白你说的“以上建议正是来自于rod”指的是什么建议？请把你提到的“rod写的东西”贴出来，Rod写了那么多东西，我哪里知道你究竟指的是什么？

BTW:我跟贴不是为了面子和辩论争上风，如果还是这种口舌之争的话，我就不准备浪费自己的时间争下去了。

第一：
我前面说的每一句话，基本上都来自于rod或Howard
我不想费心解释，是因为我觉得你应该会明白
既然你要证据，我来证明我上面说的每一句话
关于“mock是完全透明的测试，会是测试变得脆弱”，见without ejb中文版第429页第31行
关于“测试的操作越复杂，mock的成本就越高”，见without ejb中文版第430页第7行
关于stub的使用和评价，见without ejb中文版442页第18行及下文（当时还没有spring mock包和test包，所以那里面的话也要根据当时和现在的情况来理解）
关于spring mock包的由来以及他们如何使用这个包，在rod的blog上应该有，我忘记是什么时候看到的了
关于spring为什么不在pojo上为部署加入附加组件模型，在Hivemind的作者Howard Lewis Ship的blog上有

第二：
你总是拿着spring的测试60%是用easymock写的来支持自己的观点本身就错了
因为spring的测试是为了测试框架，而我们是为了测试应用
框架有天生的内聚性和耦合性，以及内部接口API的稳定性，尤其大型的框架内部组件有更多的不完整性，所以框架的测试适用于大量采用mock
而应用面对的是多变的逻辑和数据结构，甚至库表结构，使用mock进行大量的白盒测试无异于自寻死路（当然，mock也可以不这么用，只要让受益大于损耗就行了）
至于框架测试和应用测试有什么不同，rod在without ejb里只是提了一句，并没有详细说明（440页第3行），但是这个道理显而易见
我以前曾在国外某个大学的实验室的网站上看到过一篇资料说这个，不过刚才搜过，搜不到了
这方面的资料很少，大家说起test都在说unittest和mocktest的工具如何如何好用，解决了什么问题，但很少有关注在什么场景下使用以及如何正确和有效的使用的文字出现。

第三：
不承认mock测试方法的思想同其他测试方法的相似之处
就如同认为mock是从外太空飞来的工具一样，无法追根述源

第四：
这里本来就没有什么面子问题，是你太在意了
我只是觉得你灌输了一个错误的思想给别人，鉴于你的影响力，会影响到springside的作风（显然，你对白衣有很大的影响）

BTW:
我说得少是因为我觉得你的水平应该想得到，只是没有用心去想我的话
我一向敬重你在技术方面表现出的稳重，但是如果你判断一个ID说出来的话是否值得思考是根据这个ID的熟悉程度或曾经给你留下的印象，那才真是遗憾

还有，你说到面子，我想说说关于讨论这个事情
很多东西，都只是我脑海里的一个观念，原文在哪里看到都已经太久不记得了，或者已经搜不到了（我想你也应该一样），without EJB也是翻了半天才在一摞书下找到，然后再翻了半天才找到原文出处，如果有不周全的地方，我也没办法

也不要抓住某个语病不放，没人能把话都说全了，况且每个人的经验不同，同一个事物看法难免有小的差异，只要能得到些东西就好了

好了，什么指责的话我就不回复了，你只要仔细看看你上面每个回贴就应该明白究竟我在挑刺，还是你自己就没有根本没有表达清楚。

动态mock在测试上的成本确实比静态Mock要高，我并不否认这一点。但是并不是所有的接口都适合使用静态Mock的，如果所有接口都编写静态Mock，你可以想像一下成本有多大，而动态mock正是为了解决这个问题的(当然动态Mock也不是万灵药)。实际上spring mock也只有servlet mock和jndi mock，而洽洽这种通用接口是应该使用静态Mock而不是动态Mock的场合。对于绝大多数Service接口和DAO接口，我认为动态mock是很合适的选择。其实Rod Johnson也明确提出了选择mock的方针，请看without ejb 430页最上面的内容。而且再退一步来说，spring mock并没有提供你自己项目里面的Service接口和DAO接口的Mock类，那么你会怎么做？根本就不Mock了，不做单元测试了？


嗯，你的观点是框架测试适合大量使用mock，而应用测试不适合。那么请问，我如何对应用项目进行单元测试？如果你不建议大量使用mock，那么你怎么对应用代码进行单元测试？

"一人犯错 全家光荣" 这应该是个大的命题. 也许这是一个面向对象还是面向服务的问题. 以及整个web框架结构的问题.

强调用"技术"手段绕过框架本身的问题 我感觉没什么意义. 对深入讨论也没什么帮助. 每个人都有自己的技巧 没必要为**技术做免费广告.

但是应该考虑为此付出的代价有多大 能彻底解决这个问题吗 ? 自以为是的强势作风对讨论没有帮助.