When I want to rescue legacy code, I reach for Mockito. When I want to design for new features, I reach for JMock.
By default, JMock assumes that a test double (a “mock”) expects clients not to invoke anything at any time.
On the other hand, Mockito assumes that a test double (sadly, also a “mock”) allows clients to invoke anything at any time.
When I work with legacy code, I mostly write learning tests to discover how different parts of that legacy code behaves. Usually legacy code has obscene and overwhelming levels of interdependency, and Mockito helps me manage that, by allowing me to worry about one crazy dependency at a time.
When I design for new features, I mostly write design tests that describe the new behavior I want to implement. With the nice green field of a new interface, I need JMock to encourage me to clarify the interaction I need. Whenever my production code attempts to use a collaborator, JMock effectively reminds me to ensure that I want that interaction. Most importantly, JMock stops me from introducing dependencies that I don’t need.
Mockito helps me tolerate high accidental complexity while I work to reduce it.
JMock tries its best to stop me from introducing accidental complexity.