Second call to "when" fails when mocking a Spring @Cacheable

Using Mockito 2.23.0 with Spring Boot 2.0.3, we cannot get Mockito to work with Spring’s @Cacheable annotation in an integration test.

Class under test

@Component
public class MyClass {
  @Cacheable
  public String mockMe(String message) {
    return message;
  }
}

Test configuration

  @Configuration
  public static class TestConfiguration {
    @Bean
    public MyClass myClass() {
      return Mockito.mock(MyClass.class);
    }
  }

Test class

@Autowire
private MyClass myClass;

@Test
public void mockMe_test1() {
  when(myClass.mockMe(eq("Hello")).thenReturn("Mock response 1");
}
@Test
public void mockMe_test2() {
  when(myClass.mockMe(eq("Goodbye"))).thenReturn("Mock response 2");
}

What do you expect to happen? I expect both calls to when to succeed.

What actually happens? Both tests are green when ran individually. When ran together, the first test succeeds and the second call fails.

org.mockito.exceptions.misusing.InvalidUseOfMatchersException: (...)
You cannot use argument matchers outside of verification or stubbing.

Without @Cacheable on MyClass, both tests succeed. I suspect that Cacheable “caches” the call to when, making the resulting object non-mockable when called a second time. How do we remedy this?

Let me know if I should put a full example up on GitHub. I first want to check if this is a known issue or if we are doing anything wrong on our end.

[Oduig]

I’ve always been very reasonable about my open source contributions, making an effort to help resolve issues. Extracting pieces of a framework into an individually compilable and working unit is not something that I’ve ever encountered as a requirement for a bug report. I honestly think you are asking for too much, making me jump through hoops just to prove my issue is valid, when I think I’ve already demonstrated that. The burden of debugging should not be on the one reporting the issue.

[TimvdLippe]

You can copy the annotation and processing logic and remove all implementation details until you have a minimal example that fails. We have an extensive set of bugs test that are the minimal examples of the original issues (links to the original issues are usually in the source code): https://github.com/mockito/mockito/tree/release/3.x/src/test/java/org/mockitousage/bugs

For example, https://github.com/mockito/mockito/blob/release/3.x/src/test/java/org/mockitousage/bugs/FinalHashCodeAndEqualsRaiseNPEInInitMocksTest.java is the distilled version of https://github.com/mockito/mockito/issues/327 which included a lot of code originally.