EasyMock import static org.easymock.classextension.EasyMock.*;
List mock = createNiceMock(List.class);
expect(mock.get(0)).andStubReturn("one");
expect(mock.get(1)).andStubReturn("two");
mock.clear();
replay(mock);
someCodeThatInteractsWithMock();
verify(mock); Mockito import static org.mockito.Mockito.*;
List mock = mock(List.class);
when(mock.get(0)).thenReturn("one");
when(mock.get(1)).thenReturn("two");
someCodeThatInteractsWithMock();
verify(mock).clear(); Similarities- allow the same level verification as EasyMock (unexpected invocations, redundant invocations, verification in order)
- argument matchers (anyInt(), anyObject(), etc.)
Differences- only one kind of mock (no nice/default/strict mocks). Using EasyMock metaphor: Mockito mocks can be nice or strict - but it depends on how you verify mocks, not how you create them. Because there is only one kind of mock - it is easier to share setup (situations where mocks are fields in test class but different test methods require different kinds of mocks).
- no record/replay modes - no need for them. There only 2 things you can do with Mockito mocks - verify or stub. Stubbing goes before execution and verification afterwards.
- all mocks are 'nice' (even nicer, because collection-returning methods return empty collections instead of nulls). Even though mocks are nice, you can verify them as strictly as you want and detect any unwanted interaction.
- explicit language for better readability: verify() and stub() instead of mixture of expect() and ordinary method calls on mocks.
- simplified stubbing model - stubbed methods replay all the time with stubbed value no matter how many times they are called. Works exactly like EasyMock's andStubReturn(), andStubThrow(). Also, you can stub with different return values for different arguments (like in EasyMock).
- Verification of stubbed methods is optional because usually it's more important to test if the stubbed value is used correctly rather than where's it come from.
- verification is explicit - verification errors point at line of code showing what interaction failed.
- only one way of creating mocks (no MockControl object).
- verification in order is flexible and doesn't require to verify every single interaction.
- custom argument matchers use hamcrest matchers, so you can use your existing hamcrest matchers. (EasyMock also integrates with hamcrest, see the documentation of hamcrest).
Verification in orderEasyMock Control control = createStrictControl();
List one = control.createMock(List.class);
List two = control.createMock(List.class);
expect(one.add("one")).andReturn(true);
expect(two.add("two")).andReturn(true);
control.replay();
someCodeThatInteractsWithMocks();
control.verify(); Mockito List one = mock(List.class);
List two = mock(List.class);
someCodeThatInteractsWithMocks();
InOrder inOrder = inOrder(one, two);
inOrder.verify(one).add("one");
inOrder.verify(two).add("two"); Stubbing void methodsEasyMock List mock = createNiceMock(List.class);
mock.clear();
expectLastCall().andThrow(new RuntimeException());
replay(mock); Mockito List mock = mock(List.class);
doThrow(new RuntimeException()).when(mock).clear(); Exact number of times verification and argument matchersEasyMock List mock = createNiceMock(List.class);
mock.clear();
expectLastCall().times(3);
expect(mock.add(anyObject())).andReturn(true).atLeastOnce();
someCodeThatInteractsWithMock();
replay(mock); Mockito List mock = mock(List.class);
someCodeThatInteractsWithMock();
verify(mock, times(3)).clear();
verify(mock, atLeastOnce()).add(anyObject());
|
Sign in to add a comment
to be fair to easymock you can do: mock.clear(); expectLastCall().times(3);
Fair enough but 3X mock.clear() looks clearer IMHO.
Until mock.clear(); expectLastCall().times(1000); happens :P
Point taken, I've changed the EasyMock? example. Test with expectLastCall().times(1000); is pretty scary, though :)