JMock vs. EasyMock

March 2006

 

Difference EasyMock jMock Favors (reason)
Test method identification Actual method String EasyMock (code completion and refactoring works better)
Special test case class none MockObjectTestCase EasyMock (no special test case class required)
Mixing class mocking with interface mocking Use MockClassControl for mocking classes and ClassControl for mocking interfaces The classes used for mocking classes and interfaces have the same class names, but different package names (org.jmock.Mock and org.jmock.cglib.Mock, for example) EasyMock (must specify full package names of classes when mixing class and interface mocking with jMock)
Control object Requires control object (Not required in 2.0) No control object jMock (one less class to instantiate per mock)
Mock object activation Required via control.replay() Not required jMock (no activation step required)
Custom argument matching Difficult Simple jMock
API complexity 2 classes and 1 interface (with javadoc comments) 73 classes and 18 interfaces (without javadoc comments) EasyMock

 

 

  JMock EasyMock

latest version

1.0.1 - 6/2005 2.0  - 12/2005

features:

   
Direct method calls ( so refactoring & code completion work )  
Special test case class required  
Requires control object (easy Mock1.3 only)  
Easy custom argument matching  

asyMock 2.0 requires:

cglib 2.1 http://prdownloads.sourceforge.net/cglib/cglib-nodep-2.1_3.jar?use_mirror=easynews
asm 1.5.3 http://forge.objectweb.org/project/download.php?group_id=23&file_id=3083
 

Note: Comments from Fowler below are based on EasyMock 1.x,  the 2.0 version is simpler and more flexible ..ajm.

"EasyMock uses a record/replay metaphor for setting expectations. For each object you wish to mock you create a control and mock object. The mock satisfies the interface of the secondary object, the control gives you additional features. To indicate an expectation you call the method, with the arguments you expect on the mock. You follow this with a call to the control if you want a return value. Once you've finished setting expectations you call replay on the control - at which point the mock finishes the recording and is ready to respond to the primary object. Once done you call verify on the control.

It seems that while people are often fazed at first sight by the record/replay metaphor, they quickly get used to it. It has an advantage over the constraints of jMock in that you are making actual method calls to the mock rather than specifying method names in strings. This means you get to use code-completion in your IDE and any refactoring of method names will automatically update the tests. The downside is that you can't have the looser constraints. " Fowler

Teton Cay Group, Inc 2006.  Some rights reserved.

 

contact     home