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).
Comment From: 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.
Comment From: 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 https://github.com/spring-projects/spring-boot/issues/22416 for details of the problem that it addressed.
Comment From: 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.
Comment From: 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.
Comment From: wilkinsona
@bclozel another issue that could be moved to Framework to consider in the context of @MockitoBean