Missing @Mock for @InjectMocks silently fails when it cannot find the dependency

[dellinger]

Missing @Mock for @InjectMocks silently fails when it cannot find the dependency

[tvinke]

Far overdue, but for what it's worth: I quoted your reaction at the end of my article, under heading "Edit July 2020":
https://tedvinke.wordpress.com/2014/02/13/mockito-why-you-should-not-use-injectmocks-annotation-to-autowire-fields/#edit-july-2020

[bric3]

Hi,

tl;dr It would probably be possible to add a boolean flag in the annotation (a PR is welcome). Or today it's possible to change the AnnotationEngine via the IMockitoConfiguration, and then provide a tweaked engine for one's needs.

longer answer

Comments on this blog post are closed, so I'm writing here.

This feature has history and is designed that way for a reason.

The author think or say people think that Mockito injection somehow follows Spring's @Autowired annotation processing, it just isn't!

People like the way how Mockito is able to mock Spring’s auto-wired fields with the @InjectMocks annotation.

Nowhere in the javadoc, Spring, @Autowired, @Inject, etc is mentioned. And the shown behavior is documented. In that sense this blog post advocates to read the javadoc when one is using some product!

This feature was implemented when annotation based injection wasn't even there in spring or in JEE.
And anyway the code being tested may even not live inside a Spring container, the code may even be legacy, i.e. without proper separation of concerns, the code may have various valid combination to initialize the bean (setters, fields), the code may have no tests at all. Still when one have to test these kind of code be it the full object or just a portion, it was kinda useful to have a framework that just did the boilerplate code.
Also note that so many Spring beans or maybe custom WhateverCompany beans have optional setters, i.e. they have default component.

So yes it fails silently, because Mockito is not able to confirm an object is correctly initialized or not when this object relies on fields/setters, it's just impossible. And yes constructor injection is probably the best and the correct approach to dependency injection as the author even suggest (as a reminder @InjectMocks tries first to use constructor injection) ; I totally agree that the bean-y way (ie via fields/setters) to design object initialization is flawed.

The bottom line being @InjectMocks feature in mockito was never designed to be a full featured dependency injection mechanism and will probably never be. At best it's shorthand way to inject mocks, but that's all.

[dellinger]

Thank you for taking the time to explain. I think I may get ambitious this weekend and create a pull request.

[bric3]

No problem :)
Bugs happen all the time, but if it's in the javadoc, there's usually a valid reason. This post criticize the choices but point the wrong thing i.e. mockito for the reason I explained above.

Nowaday it may be reasonable to propose a boolean flag that can check that all fields are injected with a mock.

[black-snow]

Some grave digging: What about some argument for @InjectMocks to limit it to certain kinds of initialization? Like @InjeckMocks(via = org.mockito.whatevs.ConstructorInjection) and let it fail if that didn't work? Adding new parameters to constructors should then explcitly fail a test (unless you mocked the new thing before already - for some reason).

Maybe even combine it with a strategy to choose the constructor to tackle #1935 ? @InjectMocks(strategy = org.mockito.whatevs.strategies.LongestParamList and MatchingSignature (trying to resolve the constructor with the mocks provided in the test) and maybe more. @bric3

[bric3]

@black-snow This is an interesting approach ; I believe this is worth a discussion, possibly leading to a prototype. That said I struggled to actually contribute to this project in the last years. Even professionally I now rarely use Mockito. I might be able to review such code though.

[black-snow]

Aight, guess I should open a new issue then.