Spies are not reset after test execution when using @SpyBean #33830
Description
I experience the same problem as in #7374: The @SpyBean on the class is not reset between test cases.
I create a small (minimal?) version to reproduce, as suggested in the mentioned issue.
See the git repo on https://github.com/feliksik/bug-reports/tree/master/spybean-spring.
For convenience, the test inline:
@DataJpaTest @ContextConfiguration(classes = SpyBeanJpa.MyConfig.class) @SpyBean(classes = EntityJpaRepo.class) class SpyBeanJpa { @Configuration("TestService") @EnableJpaRepositories({"nl.feliksik.bugs.spybean.jpa"}) @EntityScan({"nl.feliksik.bugs.spybean.jpa"}) @ComponentScan({ "nl.feliksik.bugs.spybean", }) public static class MyConfig { } @Autowired private MyService systemUnderTest; @Autowired private EntityJpaRepo jpaRepo; @BeforeEach void setUp() { // workaround for https://github.com/spring-projects/spring-boot/issues/33830 //Mockito.reset(jpaRepo); } @Test void testA_break() { RuntimeException runtimeException = new RuntimeException("We simulate a failure"); // Note that if you use the syntax that starts with when(), the real method // is called with null param. This is an unrelated issue I don't understand. doThrow(runtimeException).when(jpaRepo).saveAndFlush(any()); try { systemUnderTest.upsert("someId"); // should not reach this assertThat(true).isFalse(); } catch (RuntimeException e) { // ok assertThat(e).isEqualTo(runtimeException); } } @Test void testB_ok() { // should be ok -- but it FAILS! systemUnderTest.upsert("someId"); } }The first test mocks an exception (the test expects it, and succeeds), the second test suffers from this: it fails, as it does not expect an exception. (If I run them separately or change the alphabetic order of cases, all is fine).
The workaround I discovered is the reset() in the setup method.
Note that I could not reproduce this without the Jpa repo; but I want to simulate a database failure.
- Possibly there is some of the Jpa/Mocking magic that conflicts here?
- Is this a bug?
- If someone can point out a better way to test for database failures, that would be appreciated.