Stubbing mocks injected by MockitoAnnotations.initMocks()

[Casey Watson]

I'm having trouble understanding the intended usage of the initMocks
feature.

I have a private field in my implementation class. Typically it is
injected by spring which makes it convenient to mock for testing.

public class MyCommand
{
...
@Resource
@Mock
private MyDAO myDAO;
}

I am mocking this object in my test by calling:
MockitoAnnotations.initMocks(myCommand)

How do you recommend stubbing out the mock object without changing the
access on myDAO? Is there a way to provide default stubs for the MyDAO
class?

Thanks,
Casey

[Casey Watson]

To clarify, is there a recommended way of specifying behavior on the
mocked myDAO without changing the private access?

[Chris Bartling]

So your production code has Mockito @Mock annotations in it?  Not sure that's a good idea.  Creating your mocks directly in the SUT has a bad smell to it. 

I maintain references to mocked dependencies in my unit test case and then inject the mocks into the SUT using @InjectMocks annotation or using setter or constructor DI techniques.  Since I have references to my mocks in my test case, I can specify and verify behavior on the mocks in my test cases.  The @InjectMocks annotation allows me to DI my mock on a private field without use of setter method.  Very cool feature.

-- chris --

On Thu, Aug 5, 2010 at 4:19 PM, Casey Watson <wats...@gmail.com> wrote:

To clarify, is there a recommended way of specifying behavior on the
mocked myDAO without changing the private access?

--
You received this message because you are subscribed to the Google Groups "mockito" group.
To post to this group, send email to moc...@googlegroups.com.
To unsubscribe from this group, send email to mockito+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mockito?hl=en.

[Malte Finsterwalder]

You might want to try EasyGloss <https://easygloss.dev.java.net/> to
inject private fields in your test setup.
No @Mock-Annotation in production code needed. Fields can stay
private. The injected mock-object can be configured before injection.

Greetings,
Malte

[Bryce]

As Christ Bartling said, you shouldn't put an @Mock annotation in your
production code. And @InjectMocks mechanism is field based in
implementation not setter based.

It means, you can inject mock into private field. Following your
example it would look like :

public class MyCommand {
@Resource
private MyDAO myDAO;

public MyDao myDao() { return myDao; }
}

@RunWith(MockitoJUnitRunner.class)
public class MyCommandTest {
@InjectMocks private MyCommand testedCommand = new MyCommand();
@Mock private MyDao myDao

@Test
public void myDaoShouldNotBeNull()
{ assertNotNull(testedCommand.myDao()); }
}

And you can stub invocations in your test method using the myDao mock.

[Casey Watson]

Brilliant! Thank you all for the helpful hints.

To summarize:
* It's a bad idea to put Mockito dependencies in to production code.

* The MockitoJUnitRunner is able to take fields marked with @Mock and
inject them into properties on the object annotated with @InjectMocks.
--The javadoc is a little unclear on the behavior:
http://mockito.googlecode.com/svn/tags/latest/javadoc/org/mockito/InjectMocks.html

* This all has nothing to do with the @Resource annotation, as that is
just there for Spring.

[szczepiq]

Excellent. How would you change the javadoc to make it clearer?

Cheers,
Szczepan