How to manually do what @InjectMocks does, but with a manually created Spy?

[KARR, DAVID]

I have a test class with a "conventional" arrangement of several @Mock-ed instance variables, and one @InjectMocks-ed instance of the class under test.

In at least one test method, I need to instead create a spied instance of the CUT because of some annoying methods in the proprietary base class. Before I had @InjectMocks, I had to manually wire up all the mocked instances into my CUT instance. It appears I have to do this again, for a spied instance, because I don't know how to manually do what @InjectMocks does. Is it possible to just call something at this point in the test method to do with my spy what @InjectMocks would have done with my normal CUT?

[Eric Lefevre-Ardant]

Would MockitoAnnotations.initMocks(testClass) (on the spy'd instance, not on the spy itself) help?

Of course, as always, I recommend not using @Mock/@InjectMock at all. Too much magic.

On 13 June 2013 17:48, KARR, DAVID <dk0...@att.com> wrote:

I have a test class with a "conventional" arrangement of several @Mock-ed instance variables, and one @InjectMocks-ed instance of the class under test.

In at least one test method, I need to instead create a spied instance of the CUT because of some annoying methods in the proprietary base class.  Before I had @InjectMocks, I had to manually wire up all the mocked instances into my CUT instance.  It appears I have to do this again, for a spied instance, because I don't know how to manually do what @InjectMocks does.  Is it possible to just call something at this point in the test method to do with my spy what @InjectMocks would have done with my normal CUT?

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

[KARR, DAVID]

I’m afraid that didn’t appear to do anything.  To illustrate, my CUT class is named Bar, which has a property of type Foo that I need to inject a mocked instance of.

 

I did something like the following:

 

Bar bar = new Bar();

Bar spiedBar = spy(bar);

doReturn(...).when(spiedBar)...

MockitoAnnotations.initMocks(bar);

spiedBar.methodcall();

 

When the last line was executed, I hit a NPE in the CUT when it referenced an instance variable that should have been mocked.

 

Concerning “magic”, it’s only magic until it becomes second nature and commonly used, just like every enhancement to humankind developed over the years that was considered “magic” when it was first developed, and which we couldn’t live without now.

[KARR, DAVID]

Just so it’s clear, the expected workaround of calling a “wireCUT()” method that manually calls the setter methods on the CUT, passing in the mocked instances, did do what I expected, which is what I was hoping “MockitoAnnotations.initMocks()” would do.  I had to pass “wireCUT()” the spy, not the spied instance, in order for this to work.  I’ll use this unless I can find a cleaner and perhaps more “magical” :) way.

[Eric Lefevre-Ardant]

Sorry, I was wrong. I thought initMocks() was made to inject mock into a CUT. It's not. It's made to initialize mocks annotated with @Mock. So, in a test, you would almost only use it as initMocks(this), as an alternative to @RunWith( MockitoJUnitRunner.class).

There does not seem to be a way to do the equivalent of @InjectMock inside a method.

I'm sorry to insist, but this confusion seems to be an illustration of my point that Mockito's annotations are better left alone. It is too complicated to figure out all the available options and their behavior.

In my project, I never use @Mock; instead, I systematically declare my mocks as instance variables in the normal way (Service mockService = mock(Service.class)). The minor annoyance of writing the name of the class twice is more than compensated by the peace of mind I (and my colleagues) get by not having to think about how the @Mock are created and injected.

In fact, it often seems to me that the main consequence of adding these annotations to Mockito was to create more traffic on this mailing list.