Is it discouraged to use @Spy and @InjectMocks on the same field?

Solution 1:

It is uncommon, and arguably inappropriate, to use @Spy and @InjectMocks together.

@InjectMocks works as a sort of dependency injection for the system under test: If you have a test that defines a @Mock or @Spy of the right type, Mockito will initialize any fields in your @InjectMocks instance with those fields. This might be handy if you haven't otherwise structured your system-under-test for dependency injection (or if you use a DI framework that does field injection) and you want to replace those dependencies with mocks. It can be pretty fragile—unmatched fields will be silently ignored and will remain null if not set in an initializer—but remains a decent annotation for your system under test.

@Spy, like @Mock, is designed to set up test doubles; you should use it when you have a collaborator that you want to stub or verify. Note there that @Spy and @Mock are always meant for dependencies, and not for your system under test.

Ideally, you should not have any class that fulfills both roles in the same test, or else you may find yourself writing a test that painstakingly tests behavior that you've stubbed rather than actual production behavior. In any case it will be more difficult to tell exactly what the test covers versus the behavior you've stubbed.

Of course, this may not apply if you're trying to use Mockito to test a single method in isolation, and you want to stub calls to one method while testing the other. However, this might also be an indication that your class is violating the Single Responsibility Principle, and that you should break down the class into multiple independent classes that work together. Then, in your test, you can allow instances to have exactly one role and never need both annotations at once.

Solution 2:

Each annotation has different purposes and they don't step on each other clearly as long as you need to use partial mocks. (a.k.a. stubbing related method(s) that has been already tested and/or trusted)

For example, you have a class to test, which has dependency injection(s) that doesn't have to be real so you want to @InjectMocks. Besides, the method you are testing calls another method inside, which was already tested somewhere, or it calls external reference which was also tested most likely independently. So, you don't want to be bothered to test same method(s) more than once, and your test code should not be impacted by the out-of-scope implementation change anytime in the future.

Only @Mock & @Spy, or @Mock & @InjectMocks pairs make no sense.