mockito.ResetMocksTestExecutionListener fails on resetting mockk spy (AOP'ed bean + mockito dependency in classpath) #28604
Comments
|
Thanks for the report. Given that the root cause of the failure is in Mockk, having read the description above it's not clear to me why you have reported the problem here. We need to get the proxy's underlying target to determine whether or not it's a Mockito mock. It would appear that Mockk is intercepting the |
|
Thanks for checking the report. I see the point that it's probably Mockk who misbehaves in the root of the exception by not
8000
handling the call to It's still not very convenient to have an otherwise working test hindered by the I guess, this issue in current form could be closed as not actionable. Would it make sense for me to create an enhancement proposal to allow suppression (opt-out) of the execution of org.springframework.boot.test.mock.mockito.ResetMocksTestExecutionListener instead? |
If you aren't using Mockito then excluding it shouldn't cause a problem. If you are using Mockito then I'm not aware of a scenario where you wouldn't want |
In my case, we do have a relatively big project with some legacy. Mockito is used for older unit tests where no Spring context is involved, and consequently ResetMocksTestExecutionListener isn't invoked. The new test code uses Mockk, and all of our integration tests that do involve Spring use Mockk, and not Mockito. Even if we used Mockito with Spring, we wouldn't need ResetMocksTestExecutionListener as our strategy towards higher tier tests is, for various reasons, to minimize the use of mocks by employing fakes or real implementations wrapped with spies instead. We also generate unique ids and references for every test run and use them for assertions instead of Under normal circumstances, the unnecessary ResetMocksTestExecutionListener executions don't pose a big problem. The price of scanning the application context after every test is negligible. But when we have something misbehaving in this context - like the issue we discuss, even though this misbehaviour might be rooted elsewhere - it would've been nice to have a simple option to opt-out of the ResetMocksTestExecutionListener while the root cause is being sorted out. |
|
It has occurred to me that it's already possible to do what you want using a |
|
Great - the DefaultTestExecutionListenersPostProcessor worked: class SuppressMockitoResetMocksTestExecutionListener : DefaultTestExecutionListenersPostProcessor {
override fun postProcessDefaultTestExecutionListeners(listeners: Set<Class<out TestExecutionListener>>): Set<Class<out TestExecutionListener>> {
return listeners.filter {it != org.springframework.boot.test.mock.mockito.ResetMocksTestExecutionListener::class.java}.toSet()
}
}Which provides are more structural solution to the potential test listener hiccups problem - and I don't see a reason to keep this issue open. Thanks a lot for the support, @wilkinsona! |
|
Excellent. Thanks for giving it a try and letting us know it worked. |
Uh oh!
There was an error while loading. Please reload this page.
Given dependency on
org.springframework.boot:spring-boot-starter-test(tested 2.5.6) with mockito in classpathWhen using mockk's spies to wrap Spring-managed beans
And those beans happen to be AOP'ed (e.g.
@Cacheableetc.)An unexpected error featuring mockito SpringBootMockResolver is observed upon the tests teardown (full stacktrace further down below):
Steps to reproduce
(demo project at https://github.com/mgurov/mockk-v-cached/tree/spring-boot/issues%2F28604 )
Given gradle dependencies
and a bean:
When the bean is wrapped by a mockk spy and injected back to the Spring context:
The following test crashes ResetMocksTestExecutionListener:
with the stacktrace:
No exception is observed when the
@Cacheableannotation is commented out on the target bean.Expected behavior
No crashes, and definitely not from a mockito-specific test listener
Workarounds
The text was updated successfully, but these errors were encountered: