Переопределение bean-компонентов Spring boot 2.1 против первичного

Переопределение bean-компонентов означает, что в контексте может быть только один bean-компонент с уникальным именем или идентификатором. Таким образом, вы можете предоставить два bean-компонента следующим образом:

package com.stackoverflow.foo;
@Configuration
public class BaseConfiguration {
   @Bean
   @Lazy
   public BService bService1() {
       return new BService();
   }
}

package com.stackoverflow.bar;
@Configuration
@Import({BaseConfiguration.class})
public class TestConfiguration {
    @Bean
    public BService bService2() {
        return Mockito.mock(BService.class);
    }
}

Если вы добавите @Primary, то первичный компонент будет внедрен по умолчанию в:

@Autowired
BService bService;

По умолчанию разрешено заменять @Component на @Bean. В твоем случае

@Service
public class AService {
}

@Component
public class BService {
    @Autowired
    public BService() { ... }
}

@Configuration
@ComponentScan
public BaseConfiguration {
}

@Configuration
// WARNING! Doesn't work with @SpringBootTest annotation
@Import({BaseConfiguration.class})
public class TestConfiguration {
    @Bean // you allowed to override @Component with @Bean.
    public BService bService() {
        return Mockito.mock(BService.class);
    }
}

spring.main.allow-bean-definition-overriding=true можно разместить в тестовых конфигурациях. Если вам нужно обширное интеграционное тестирование, вам нужно будет в какой-то момент переопределить bean-компоненты. Это неизбежно.

Хотя правильный ответ уже был предоставлен, это означает, что у вашего bean-компонента будут разные имена. Так что технически это не переопределение.

Если вам нужно реальное переопределение (потому что вы используете @Qualifiers, @Resources или что-то подобное), поскольку Spring Boot 2.X возможен только с использованием свойства spring.main.allow-bean-definition-overriding=true.

Обновлять: Будьте осторожны с Kotlin Bean Definition DSL. В Spring Boot потребуется настраиваемый ApplicationContextInitializer, например:

class BeansInitializer : ApplicationContextInitializer<GenericApplicationContext> {

    override fun initialize(context: GenericApplicationContext) =
            beans.initialize(context)

}

Теперь, если вы решите переопределить один из таких компонентов на основе DSL в своем тесте с помощью метода @Primary @Bean, этого не будет. Инициализатор сработает после методов @Bean, и вы все равно получите начальный компонент на основе DSL в своих тестах даже с @Primary на тестовом @Bean. Еще один вариант - также создать инициализатор теста для ваших тестов и перечислить их все в ваших свойствах теста, например (порядок имеет значение):

context:
    initializer:
        classes: com.yuranos.BeansInitializer, com.yuranos.TestBeansInitializer

DSL определения компонента также поддерживает первичное свойство через:

bean(isPrimary=true) {...}

- что вам нужно для устранения двусмысленности при попытке внедрить bean-компонент, однако main:allow-bean-definition-overriding: true не нужен, если вы идете по пути чистого DSL.

(Весенняя загрузка 2.1.3)

Я делаю тестовые bean-компоненты доступными только в профиле test и разрешаю переопределение только во время тестирования, например:

@ActiveProfiles("test")
@SpringBootTest(properties = {"spring.main.allow-bean-definition-overriding=true"})
class FooBarApplicationTests {

  @Test
  void contextLoads() {}
}

Бин, над которым я издеваюсь в тестовой конфигурации:

@Profile("test")
@Configuration
public class FooBarApplicationTestConfiguration {
  @Bean
  @Primary
  public SomeBean someBean() {
    return Mockito.mock(SomeBean.class);
  }
}