Spring--也许正成为一个EJB

http://www.iteye.com/problems/62911

觉得spring那么NB的话，帮忙回答下这个问题

小兄弟呀，接口的实现类是不是你自己写的？对于业务实现，你是要测试接口还是实现类呢？


OK，我来细细说一下，自己定义的接口难道还搞一个Mock去测试，为什么要Mock，你看看Spring Test里面，它是针对JEE标准接口而言，比如ServletRequest这类的接口，因为标准技术提供一个规约，这个具体实现不用关心，JEE容器提供实现。容器方面的话，你不用太过于测试。但是在你的单元测试代码中依赖了这些接口，通过Mock的方法来模拟输入，断言输出。

你说的Action一起测试的问题，是单元测试粒度的问题。

对于业务实现，你都自己知道怎么实现的啦，还要去Mock一个对象吗？

比如：

A 类依赖于 B接口，那么你很清楚B接口只有一个实现B1，那么你在做A的单元测试的时候，有必要去做B的Mock吗？

在其他地方传入B接口实例是就是B1,为什么不直接传入B1实例呢？前提是B1的单元测试必须保证，即使没有保证的话，可以通过A的单元测试回归。

所以，你所说的“那朝所谓的技术小牛也越来越远了”，过于理论化，学习技术建议抱有怀疑的态度，什么能做比较重要，不能做更重要！

最后，送你一句话吧！纸上得来终觉浅，绝知此事要躬行

翻了9页还没看到特别有水准的评论，也不翻了。按照惯例，这应该是JavaEye每半年就会出现的吵架帖。以后肉饼应该感谢你们的话题带来的流量了。
Spring一个比较特别的地方就是让新手写出的代码看起来没那么差。

要对action做单元测试，说明你的代码中，action充刺着大量本不属于action的职责，action本身是简单的，对action做测试，就是蛋疼行为，1＋1＝2需要测试吗？相应的包括什么service测试，dao测试，都需要个mock对象，我不否定mock。但也不是什么都用个mock。如果一个类可以自测试，我还要这些xxx注入干什么。就是因为需要xxx注入，所以项目代码一大坨，测试代也一大坨。

就是因为现在我们用的是maven+jenkins+sonar 所以有jenkins做持续构建并跑单元测试覆盖率,正因为我们现在的团队人数多,所以开发时不是由一个人从action写到dao,而是横切并行开发的,由专门的人写servcie和公用service.所以自己写的action自己要写mokc单元测试,而不是串行的等待其他人的servcie写完再测,至少是自扫门前雪,action行覆盖率要到85%,service的覆盖率要到90%.这也许与开发模式相关.但相比以前自己写个网页点点,算是从action测到dao层,至少从项目上线后一个月看,不像以前狂改bug了,整个项目的bug都集中在页面的体验上了,而不是诡异的throw null啊,业务逻辑异常.这个就是我的体验,不知道算不算绝知此事已躬行

这个我只能说,在系统中1+1=2是需要测试的。你自己没有实现junit，不代表没有项目没有实现，如果举大点，现在稍微著名的开源框架或工具都有junit的代码的，这才能保证该框架或工具至少不是满地bug的。我建议你可以看看单元测试的内容，不管是传统的瀑布开发模型还是最新的敏捷模型，都要求单元模块测试，这是基础。“action本身是简单的，对action做测试，就是蛋疼行为”这是想当然的行为，“用眼睛看看猪肉质量就可以了，是简单的，所以不用仪器检测，所以瘦肉精猪肉就进来了，双汇就蛋疼了"

看看我前面的帖子，如果是远程调用或者API级别，是要做Mock确实没有错。这是单元测试的策略问题，呵呵。如果多部门的协作就复杂了，建议还是不要设计复杂的接口类型，采用简单类型过度，等需要的时候在添加上去，这样你没有办法保证接口实现是不是100%可靠，到时候他那边做了任何修改，如果没有通知到你的话，这样事故责任不好定位。因此，这些是开发流程的问题。但不是每个实现都需要接口，上面的意思是说过度设计接口带来了负责，其实没有必要。一个简单的功能没有必要用多层封装，保持简单就OK了。