-
Notifications
You must be signed in to change notification settings - Fork 41.1k
@MockBean leads to Mockito Validation Exceptions presumably masking problems with @Async annotated services #6573
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
The problem is that What's the reason for having |
Must have happened when I extracted the interface via IntelliJ. I removed the annotation from the interface which resulted in the passing test you described while keeping the async behavior in production. I tested the same for spying instead of mocking and the conclusion was the same. I could kick myself for that one. Sorry for wasting your time and thank you for the quick response! |
No apology needed. Ideally, it wouldn't matter if |
Thank you very much for that! If I can anyhow provide useful input just let me know. |
We might be able to enhance |
Unfortunately, we're not within |
I think the best we can do here is to fail fast when we encounter |
I believe I had the same issue when using a I changed the bean to use an interface and dropped the 'proxyTargetClass=true' attribute and it now works fine as a mock. Perhaps at this stage it might be worth just making a mention in the documentation and seeing how much it impacts people? |
I was expecting caching to be affected by this as well. Thanks for sharing that feedback @patrickherrera ! |
Post-processing of mocked beans causes a number of problems: - The mock may be proxied for asynchronous processing which can cause problems when configuring expectations on a mock (spring-projectsgh-6573) - The mock may be proxied so that its return values can be cached or so that its methods can be transactional. This causes problems with verification of the expected calls to a mock (spring-projectsgh-6573, spring-projectsgh-5837) - If the mock is created from a class that uses field injection, the container will attempt to inject values into its fields. This causes problems if the mock is being created to avoid the use of one of those dependencies (spring-projectsgh-6663) - Proxying a mocked bean can lead to a JDK proxy being created (if proxyTargetClass=false) as the mock implements a Mockito interface. This can then cause injection failures as the types don’t match (spring-projectsgh-6405, spring-projectsgh-6665) All of these problems can be avoided if a mocked bean is not post-processed. Avoiding post-processing prevents proxies from being created and autowiring from being performed. This commit avoids post-processing by registering mocked beans as singletons rather than via a bean definition.
Hello everyone,
I have been experimenting with the Mockito integration in the new 1.4.0.RELEASE version of spring boot and encountered some difficulties while writing some tests.
I wrote a controller, which injects a service bean and calls an async method (async configuration is written to return a ThreadPoolTaskExecutor). When using the
@MockBean
annotation on the service in my test class all usages of parameter matchers fail (either while configuring in before method using given/willReturn or while verifying method calls).I wrote a basic project illustrating this behavior - it can be found at https://github.com/WalternativE/mocking-bug . The tag "problem" contains the failing test while the tag "workaround" contains the profile configuration deactivating the async configuration for the test (the test passes without exception).
While researching the errors I stumbled upon issue #6405 - could be linked to that to some extend. I tried playing around with the proxyTargetClass parameter but I had no luck there.
While debugging the test cases I got the expected behavior while inspecting the mocked service with the IntelliJ Idea debugging tools - might have resolved some proxies manually which maybe cannot be resolved reflectively by Mockito (but that's just guesswork - haven't had the opportunity to reproduce that yet).
Thanks,
Gregor
The text was updated successfully, but these errors were encountered: