I remember a Dilbert strip regarding pointy hair boss solving a wrong problem.
Saw this the other day - https://tedvinke.wordpress.com/2014/02/13/mockito-why-you-should-not-use-injectmocks-annotation-to-autowire-fields/
Though the problem regarding not using constructor is right, as it ends up giving a partially created class object in the test, but putting the blame on InjectMocks is totally wrong.
Injectmocks does what it suppose to do, if the developer is not following good programming practices, and is not aware which dependencies will get used in the unit test flow, then you cant blame the framework.
Just to go bit off topic, I had problem with InjectMocks, even after providing all the autowired beans, it jumbled them up. Reason - There were couple of prototype beans and I was injecting the Provider interface in the constructor. Here mockito was getting confused in mapping the correct providers . There I was forced to use the manual initialising of SUT using constructor. Not sure if the problem exists in the newer versions also.
Saw this the other day - https://tedvinke.wordpress.com/2014/02/13/mockito-why-you-should-not-use-injectmocks-annotation-to-autowire-fields/
Though the problem regarding not using constructor is right, as it ends up giving a partially created class object in the test, but putting the blame on InjectMocks is totally wrong.
Injectmocks does what it suppose to do, if the developer is not following good programming practices, and is not aware which dependencies will get used in the unit test flow, then you cant blame the framework.
Just to go bit off topic, I had problem with InjectMocks, even after providing all the autowired beans, it jumbled them up. Reason - There were couple of prototype beans and I was injecting the Provider interface in the constructor. Here mockito was getting confused in mapping the correct providers . There I was forced to use the manual initialising of SUT using constructor. Not sure if the problem exists in the newer versions also.
