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:

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