@MockBean leads to Mockito Validation Exceptions presumably masking problems with @Async annotated services

[WalternativE]

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

[wilkinsona]

The problem is that SimpleService.doTask is annotated with @Async. This means that the mock of that interface is automatically proxied for asynchronous execution. As a result, there's a race condition in MockTest.init() as the call to this.simpleService.doTask() is passed to the underlying mock on a separate thread.

What's the reason for having @Async on both SimpleService.doTask() and SimpleServiceImpl.doTask()? If it's only on the latter the mock is no longer asynchronous and the test passes.

[WalternativE]

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!

[wilkinsona]

No apology needed. Ideally, it wouldn't matter if @Async was on the interface but I'm not sure how we can manage that. I'll discuss it with the rest of the team to see if they have any bright ideas.

[WalternativE]

Thank you very much for that! If I can anyhow provide useful input just let me know.

[wilkinsona]

We might be able to enhance MockitoAopProxyTargetInterceptor to bypass the async stuff within a call to when or given.

[wilkinsona]

Unfortunately, we're not within when or given when the problematic call to the mock is made. It's the result of the problematic call that's then passed into when or given by which time it's too late.

[wilkinsona]

I think the best we can do here is to fail fast when we encounter @Async on an interface that's going to be mocked. However, that would be a false positive if the test doesn't also have async processing enabled so we'd need to detect that too. We'd also need to consider extra interfaces configured via MockBean's extraInterfaces attribute.

[patrickherrera]

I believe I had the same issue when using a @Cacheable method on a mocked bean. I was using a straight class via @EnableCaching(proxyTargetClass=true) and the caching system would complain because it was getting null values for the cache key when the mocked method was called.

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?

[snicoll]

I was expecting caching to be affected by this as well. Thanks for sharing that feedback @patrickherrera !