SpyBean does not necessary spy on the primary bean when there are 2 instance

[lsiu]

When there are 2 beans and one marked as @Primary, in normal auto-wiring, the Primary bean is used. However, in case of test code autowired via @SpyBean, this is not necessary the case. This cause unexpected behavior when using the spybean to mock responses on methods.

I have created a sample project which illustrate this. See the test class and the same code

Looking more into the details. It appear which bean is spied on depends on the order the beans are returned from the method getExistingBeans in MockitoPostProcessor (the last bean return ends up being the one is spied on, since the loop in registerSpies essential overwrite previous spy registered). I would expect we always spy on the bean marked with @Primary similar to the normal auto-wiring behavior.

[philwebb]

Thanks for the sample project. There's certainly an issue here but I'm not sure that it's directly related to @Primary. The MockitoPostProcessor should throw an exception because there is more than one candidate bean, however, the field is null. It appears that a new DefinitionsParser is being created and the field mappings are being lost.

[lsiu]

Throwing an error is not an idea solution, since in production code, we do allow multiple beans and resolve using the @Primary bean annotation.

Resolving the Bean to mock or spy or should be same as how it is done in the production code. Is it possible to just reuse the same code? For example, I see DefaultListableBeanFactory.determineAutowireCandidate is use to resolve when there are multiple autowire candidate.

I have not fully investigate this yet, but I would think instead of spring-boot-test having its own logic to "pick" the bean to mock/spy on, it should delegate to the BeanFactory to resolve it.

[philwebb]

@lsiu I see your point, but it's more than just picking the bean. It also needs to update the bean definition in the context. Let me have a think about the options.

[lsiu]

@philwebb - I have created 2 tests that illustrate the problem and a proposed fix with the above commit (9f5c777). It may not be the best place to fix it, but it does fix the issue and doesn't break the other tests.

[philwebb]

Thanks @lsiu! We discussed this a little on our regular team call and we think using the @Primary bean as the spy source is the best option.