Spring Boot: создание собственной автоконфигурации, тестирование собственной автоконфигурации

На автоконфигурацию могут влиять многие факторы: конфигурация пользователя (определение @Bean и настройка Environment), оценка состояния (наличие определенной библиотеки) и другие. Конкретно, каждый тест должен создавать четко определенный ApplicationContext, представляющий комбинацию этих настроек. ApplicationContextRunner предоставляет отличный способ достичь этого.

ApplicationContextRunner обычно определяется как поле тестового класса для сбора базовой, общей конфигурации. В следующем примере показано, что UserServiceAutoConfiguration всегда вызывается:

private final ApplicationContextRunner contextRunner = new ApplicationContextRunner()
        .withConfiguration(AutoConfigurations.of(UserServiceAutoConfiguration.class));

Если необходимо определить несколько автоконфигураций, нет необходимости упорядочивать их объявления, так как они вызываются в том же порядке, что и при запуске приложения.

Каждый тест может использовать runner для представления конкретного варианта использования. Например, в приведенном ниже примере вызывается конфигурация пользователя (UserConfiguration) и проверяется, что автоконфигурация корректно отключается. Вызов run предоставляет контекст обратного вызова, который можно использовать с Assert4J.

@Test
void defaultServiceBacksOff() {
    this.contextRunner.withUserConfiguration(UserConfiguration.class).run((context) -> {
        assertThat(context).hasSingleBean(UserService.class);
        assertThat(context).getBean("myUserService").isSameAs(context.getBean(UserService.class));
    });
}

@Configuration(proxyBeanMethods = false)
static class UserConfiguration {

    @Bean
    UserService myUserService() {
        return new UserService("mine");
    }

}

Также можно легко настроить Environment, как показано в следующем примере:

@Test
void serviceNameCanBeConfigured() {
    this.contextRunner.withPropertyValues("user.name=test123").run((context) -> {
        assertThat(context).hasSingleBean(UserService.class);
        assertThat(context.getBean(UserService.class).getName()).isEqualTo("test123");
    });
}

runner также может быть использован для отображения ConditionEvaluationReport. Отчет может быть распечатан на уровне INFO или DEBUG. В следующем примере показано, как использовать ConditionEvaluationReportLoggingListener для печати отчета в тестах автоматической настройки.

@Test
public void autoConfigTest {
    ConditionEvaluationReportLoggingListener initializer = new ConditionEvaluationReportLoggingListener(
            LogLevel.INFO);
    ApplicationContextRunner contextRunner = new ApplicationContextRunner()
            .withInitializer(initializer).run((context) -> {
                    // Делаем что-либо...
            });
}

Имитация веб-контекста

Если вам нужно протестировать автоконфигурацию, которая работает только в контексте сервлета или реактивного веб-приложения, используйте соответственно WebApplicationContextRunner или ReactiveWebApplicationContextRunner.

Переопределение пути к классам

Также возможно проверить, что происходит, когда определенный класс и/или пакет отсутствуют во время выполнения. Spring Boot поставляется с FilteredClassLoader, который может легко использоваться runner. В следующем примере утверждается, что если UserService отсутствует, автоконфигурация должным образом отключена:

@Test
void serviceIsIgnoredIfLibraryIsNotPresent() {
    this.contextRunner.withClassLoader(new FilteredClassLoader(UserService.class))
            .run((context) -> assertThat(context).doesNotHaveBean("userService"));
}

---

Читайте также:

• Spring Boot: создание собственной автоконфигурации
• Spring Boot: создание собственной автоконфигурации, аннотации условий
• Spring Boot: Web Services (веб службы)