推荐升级easymock到新的3.0版本

    一直在使用easymock作为mock工具，但是easymock有一个一直令我极其恼火的地方：easymock将interface和class的mock区分开，给出了针对interface mock的easyMock和针对class mock的easyMock class extension。两种mock被严格区分开，连jar包都是两个，使用时不能混用，比如不能用easymock (非class extension)来mock class。

    这也就算了，最要命的地方是,easyMock和easyMock class extension在使用时，class名是相同的，只是package不同。这会导致一个非常令人抓狂的问题：如果在同一个测试类中，需要同时使用interface mock和class mock，就必须同时使用org.easymock.EasyMock和org.easymock.classextension.EasyMock，由于java import只能import一个，因此另外一个就必须使用全限定名，如：

import org.easymock.EasyMock;
...
    Easymock.createMock(...);
    org.easymock.classextension.EasyMock.createMock(...);

    编码的时候稍有不慎就搞错，代码难写而且难看。很明显，这是一个没有必要的设计，因为使用者通常并不关心mock的是interface还是class。

    近日得知easymock已经发布了新的3.0版本，该版本的主要改进就是消除上述的问题，新版本中可以直接mock class，不再强制使用easyMock class extension。

    以下是easymock官网 http://easymock.org/ 的发布信息:

010-05-08: EasyMock 3.0 is available. Perform class mocking directly. EasyMock 1 classes removed.
2010-05-08: EasyMock 3.0 Class Extension is available. Now deprecated. Only a proxy over EasyMock to provide backward compatibility.

    可以看到为了兼容2.*版本的就有代码，3.0之中还是发布了Class Extension版本，作为旧有的2.*代码和新的3.0之间的代理。不过明确标记为"deprecated"了。

    试用了一下，新的3.0版本中，直接使用org.easymock.EasyMock，可以在同一个case中同时混合mock interface和class，使用方式和以往相同。恩，明显感觉使用方便了许多。

    顺便做了一下兼容性测试，针对旧有的使用2.*版本的class mock的测试案例，尝试使用两种方法：

    1. 不修改原有代码，使用3.0的class extension来保持兼容
代码编译通过，测试案例正常运行。
这个方案适合项目较大时先整体升级，保证测试案例可以运行，后续再逐步转移到3.0版本。

    2. 修改原有代码，不再使用class extension
代码只需一个改动，即将原有的org.easymock.classextension.EasyMock 修改为org.easymock.EasyMock，通常只要简单修订import即可。eclispe下简单ctrl +shit + o一招即可搞定。

    两个方法组合使用，就可以平稳的将原有的2.*的测试案例转移到新的3.0版本中。

    强烈推荐还在使用easymock 2.*的朋友们升级到3.0版本。

推荐mockito

推荐的理由是什么？能简单说一下吗？mockito我还没有接触过，不大清楚。

我们这边在用jmockit，来解决一些easymock无法做到的问题，比如模拟静态方法。

这里有一个jmockit给出来的特性对比列表，mockito也在其中。

http://code.google.com/p/jmockit/wiki/MockingToolkitComparisonMatrix

当然这个是jmockit给出来的，可能不是很公正。不过大体上看，jmockit还是很强大的。

因为mockito完全可以代替easymock，而且语法简单，功能更强，所以推荐。
jmockit我都没听说过，哈哈，看那个比较貌似jmockit更强，比如可以mock静态方法。

另外，你们为何结合使用两个mock框架，只用jmockit一个不可以么？
像我现在就是完全用mockito代替easymock了

mockito的优点很多，比较有特色的是这两个：
Argument matchers
Sometimes, when extra flexibility is required then you might use argument matchers:
//stubbing using built-in anyInt() argument matcher
when(mockedList.get(anyInt())).thenReturn("element");

Stubbing consecutive calls (iterator-style stubbing)
Sometimes we need to stub with different return value/exception for the same method call. Typical use case could be mocking iterators. Original version of Mockito did not have this feature to promote simple mocking. For example, instead of iterators one could use Iterable or simply collections. Those offer natural ways of stubbing (e.g. using real collections). In rare scenarios stubbing consecutive calls could be useful, though:

when(mock.someMethod("some arg"))
   .thenThrow(new RuntimeException())
   .thenReturn("foo");

//First call: throws runtime exception:
mock.someMethod("some arg");

//Second call: prints "foo"
System.out.println(mock.someMethod("some arg"));

//Any consecutive call: prints "foo" as well (last stubbing wins).
System.out.println(mock.someMethod("some arg"));


Alternative, shorter version of consecutive stubbing:

when(mock.someMethod("some arg"))
   .thenReturn("one", "two", "three");

http://mockito.googlecode.com/svn/tags/latest/javadoc/org/mockito/Mockito.html

这个我还真不大清楚，稍后再问问同事。我加入前就是easymock + jmockit了。

惭愧的说在此之前我还真不知道jmockit的存在，也不知道原来static方法也是可以mock的。

我猜测啊，可能是开始用easymock，后来发现有些地方easymock搞不定，因此作为补充引入的jmockit。从我看到的测试代码上看，jmockit目前都是在这些对于easymock来说比较难受的地方在使用。jmockit 自己的expection, verification好像没有看到。

正在研究jmockit中，上面引用的那个特性列表，哎，不能不再此惭愧一下，很多特性我都是不知道它的存在的，等稍后仔细过一遍在说。

几年前用过easymock，现在项目中基本没有单元测试。有，顶多也是写个main方法跑一把。

这个，未免强大了点，你们是怎么保证代码质量的？

传说中的单元测试无用论，直接集成测试。。。

我们是分层开发的，基本上算是集成测试吧。目前还不知道有那些技术能给B/S结构的做完整的单元测试。

给B/S结构的做完整的单元测试确实不容易，不过即使抛开B不谈，你的S端总的有单元测试吧？

s端的业务逻辑，实现逻辑这些都是可以用单元测试来保证质量的，我相信你们的s端怎么也不至于简单到只要得到两个参数a,b，然后直接return (a + B)这么简单吧？