I think the reason may be that mock object libraries typically create mocks by dynamically creating classes at runtime (using cglib). This means they either implement an interface at runtime (that’s what EasyMock does if I’m not mistaken), or they inherit from the class to mock (that’s what Mockito does if I’m not mistaken). Both … Read more
The best way is: <bean id=”dao” class=”org.mockito.Mockito” factory-method=”mock”> <constructor-arg value=”com.package.Dao” /> </bean> Update In the context file this mock must be listed before any autowired field depending on it is declared.
New feature added to Mockito makes this even easier, ArgumentCaptor<Person> argument = ArgumentCaptor.forClass(Person.class); verify(mock).doSomething(argument.capture()); assertEquals(“John”, argument.getValue().getName()); Take a look at Mockito documentation In case when there are more than one parameters, and capturing of only single param is desired, use other ArgumentMatchers to wrap the rest of the arguments: verify(mock).doSomething(eq(someValue), eq(someOtherValue), argument.capture()); assertEquals(“John”, argument.getValue().getName());
An alternative to ArgumentMatcher is ArgumentCaptor. Official example: ArgumentCaptor<Person> argument = ArgumentCaptor.forClass(Person.class); verify(mock).doSomething(argument.capture()); assertEquals(“John”, argument.getValue().getName()); A captor can also be defined using the @Captor annotation: @Captor ArgumentCaptor<Person> captor; //… MockitoAnnotations.initMocks(this); @Test public void test() { //… verify(mock).doSomething(captor.capture()); assertEquals(“John”, captor.getValue().getName()); }
when( fooDao.getBar( any(Bazoo.class) ) ).thenReturn(myFoo); or (to avoid nulls): when( fooDao.getBar( (Bazoo)notNull() ) ).thenReturn(myFoo); Don’t forget to import matchers (many others are available): For Mockito 2.1.0 and newer: import static org.mockito.ArgumentMatchers.*; For older versions: import static org.mockito.Matchers.*;
Mockito 2 now supports final classes and methods! But for now that’s an “incubating” feature. It requires some steps to activate it which are described in What’s New in Mockito 2: Mocking of final classes and methods is an incubating, opt-in feature. It uses a combination of Java agent instrumentation and subclassing in order to … Read more
The nested generics-problem can be avoided with the @Captor annotation: public class Test{ @Mock private Service service; @Captor private ArgumentCaptor<ArrayList<SomeType>> captor; @Before public void init(){ MockitoAnnotations.initMocks(this); } @Test public void shouldDoStuffWithListValues() { //… verify(service).doStuff(captor.capture())); } }
I think you do need to cast it, but it shouldn’t be too bad: Foo<Bar> mockFoo = (Foo<Bar>) mock(Foo.class); when(mockFoo.getValue()).thenReturn(new Bar());
Using the appropriate VerificationMode: import static org.mockito.Mockito.atLeast; import static org.mockito.Mockito.times; import static org.mockito.Mockito.verify; verify(mockObject, atLeast(2)).someMethod(“was called at least twice”); verify(mockObject, times(3)).someMethod(“was called exactly three times”);
Dependency Injection If you inject the Bar instance, or a factory that is used for creating the Bar instance (or one of the other 483 ways of doing this), you’d have the access necessary to do perform the test. Factory Example: Given a Foo class written like this: public class Foo { private BarFactory barFactory; … Read more