When using `@MockitoBean` and `@MockitoSpyBean` make it easier to inject any underlying proxy target as well as the mock or spy

[wilkinsona]

We'd like to support something like this:

@MockitoSpyBean
ProxiedBean<Service> service;

ProxiedBean would then provide accessors for the bean both with and without all of its Spring proxies. This should make it easier to bypass any caching or advice when, for example, setting expectations, while having them in place when exercising the service.

Hopefully this will address spring-projects/spring-boot#22281 by providing a nicer API that can be used in place of AopTestUtils.getTargetObject(service).

[kriegaex]

I just found this again and was wondering if somebody wants to pick up the ball left on the field for the Spring team by @raphw, having implemented that MockResolver thingy in Mockito.

[wilkinsona]

What ball are you referring to, @kriegaex? We've had SpringBootMockResolver (a Mockito MockResolver implementation) since Spring Boot 2.4. It's largely orthogonal to this issue. See spring-projects/spring-boot#22416 for details of the problem that it addressed.

[kriegaex]

I was under the impression that this issue was meant to improve the situation for the workaround I found with unwrapping proxies, as described in spring-projects/spring-boot#22281. Because it is listed as open, I thought that nothing has happened in this regard.

FYI, I am not an active Spring user and never was. Sometimes I support people on Stack Overflow with regard to Spring AOP, AspectJ or test automation with Spock and Geb. Only in those contexts do I ever use Spring at all. So forgive me for possibly not being up to date with everything happening within the Spring framework. But an open issue is an open issue, and this one is open.

[wilkinsona]

Your impression is correct. I understood your comment to be suggesting that an implementation of Mockito's MockResolver could be used in implementing the enhancement that this issue is tracking. Thanks for clarifying that this is not the case.

I'll hide these comment as they feel off-topic for the issue at hand. We do want to resolve it – hence it remaining open – but we have higher priorities at the moment.

[wilkinsona]

@bclozel another issue that could be moved to Framework to consider in the context of @MockitoBean