Override bean in Spring Boot 2.1 slice test with nested TestConfiguration

I just migrated an application from Spring Boot 1.x to 2.1. One of my test is failing due to a change to bean overriding default.

I tried to set spring.main.allow-bean-definition-overriding to true but it’s not working. I managed to make it work by using a standalone @TestConfiguration class that I import. But if it’s nested, it does not work.

You can reproduce the issue with the following classes:

@Configuration
public class ClockConfig {
    @Bean
    public Clock clock() {
        return Clock.systemUTC();
    }
}

@Service
public class MyService {
    private final Clock clock;
    public MyService(Clock clock) {
        this.clock = clock;
    }
    public Instant now() {
        return clock.instant();
    }
}

@RestController
public class MyResource {
    private final MyService myService;
    public MyResource(MyService myService) {
        this.myService = myService;
    }
    @GetMapping
    public ResponseEntity<Instant> now() {
        return ResponseEntity.ok(myService.now());
    }
}

The failing test. The clock() method is never called with Spring Boot 2.1 whereas it was with Spring Boot 1.5 or Spring Boot 2.0.

@RunWith(SpringRunner.class)
@WebMvcTest(MyResource.class)
@ContextConfiguration(classes = MyService.class)
public class ResourceTest {
    @Autowired
    private MockMvc mvc;
    @Test
    public void test() {
    }
    @TestConfiguration
    static class TestConfig {
        @Bean
        public Clock clock() {
            return Clock.fixed(Instant.MIN, ZoneId.of("Z"));
        }
    }
}

[sgflt]

I have run into this issue too after splitting big app into modules as suggested in Structuring and Testing Modules and Layers with Spring Boot

In previous monolith there some test cases had nested static class annotated by @TestConfiguration, that provided Bean EmbeddedDatasource with database manually crafted from sql scripts. After splitting app into modules there are two types of errors. Spring boot version is unchanged: v2.2.6.RELEASE.

1. org.springframework.beans.factory.support.BeanDefinitionOverrideException: Invalid bean definition with name ‘setUp’ defined in class path resource. This error is caused by @ComponentScan in module that scans multiple nested static classes each containing definition of specific datasource.

If I rearrange code to avoid ComponentScan. The second problem arrises.

1. org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type. Which complains about missing dependency in production code which is obviously not found because in module there is no ComponentScan nor SpringBootApplication.

Is there any possible solution to this situation? Respectively to preserve behavior of nested static classes in test case and test code still be able to access to production code.

Code example to better understanding:

@ExtendWith(SpringExtension.class)
@SpringBootTest
@AutoConfigureMockMvc
class TestCase {
  ...
  @TestConfiguration
  static class EmbeddedDatabaseConfiguration {
    @Bean
    @Primary
    DataSource setUp() {
     // datasource with custom data
      ...
    }
}


@ExtendWith(SpringExtension.class)
@SpringBootTest
@AutoConfigureMockMvc
class AnotherTestCase {
  ...
  @TestConfiguration
  static class EmbeddedDatabaseConfiguration {
    @Bean
    @Primary
   // this is in conflict with TestCase.EmbeddedDatabaseConfiguration after modularisation
    DataSource setUp() {
     // datasource with custom data
      ...
    }
}

Maybe it is for another issue, because my TestConfiguration is found and called, but the bean created is global and each test therefore can not mock it’s own implementation. TestConfigurations in single module app are behaving as expected.

[mbhave]

I ran the original sample and the tests which use @Import instead of @ContextConfiguration pass. I am going to close this issue because as @snicoll suggested using @ContextConfiguration in slice tests is quite unusual.

@sgflt The issue you’ve described might be slightly different because it does not involve @ContextConfiguration. If you think you’ve found a bug, please open another issue with a minimal sample that we can run to reproduce it.