Go to file
2021-08-01 02:17:38 +07:00
build_utils@a7655bc60c init project 2021-07-26 13:41:04 +07:00
readme refactoring (#13) 2021-08-01 02:17:38 +07:00
src refactoring (#13) 2021-08-01 02:17:38 +07:00
.gitignore init project 2021-07-26 13:41:04 +07:00
.gitmodules init project 2021-07-26 13:41:04 +07:00
Jenkinsfile init project 2021-07-26 13:41:04 +07:00
LICENSE init project 2021-07-26 13:41:04 +07:00
pom.xml refactoring (#13) 2021-08-01 02:17:38 +07:00
README.md Update README.md (#11) 2021-07-31 17:47:25 +07:00

testcontainers-annotations-junit5

Репозиторий с аннотациями, которые подключают и запускают тестконтейнеры (TestContainers) и инициализируют runtime настройки тестконтейнеров (url, username, password, etc) в контекст SpringBoot приложения

🚨Работает только с JUnit 5🚨

Аннотации

Проектом поддерживаются следующие docker images

postgres
confluentinc/cp-kafka
yandex/clickhouse-server
ceph/daemon
minio/minio

Базовые аннотации для использования:

@PostgresqlTestcontainer
@KafkaTestcontainer
@ClickhouseTestcontainer
@CephTestcontainer
@MinioTestcontainer

Подробная информация об каждой аннотации находится в директории readme

Для изменения docker image tag, который используется тестконтейнерами нужно переопределить параметры в application.yml:

testcontainers:
  postgresql:
    tag: '12'
  kafka:
    tag: '6.2.0'
  clickhouse:
    tag: 'latest-alpine'
  ceph:
    tag: 'v3.0.5-stable-3.0-luminous-centos-7'
    accessKey: 'test'
    secretKey: 'test'
  minio:
    tag: 'latest'
    user: 'user'
    password: 'password'

Eсли параметр не указан библиотека будет использовать параметры по умолчанию, указанные в репозитории в файле testcontainers-annotations.yml

Техническое описание инциализации настроек тестконтейнеров в контекст приложения  

Инициализация настроек контейнеров в спринговый контекст тестового приложения реализован под капотом аннотаций, на уровне реализации интерфейса ContextCustomizerFactory — информация о настройках используемого тестконтейнера и передаваемые через параметры аннотации настройки инициализируются через TestPropertyValues и сливаются с текущим получаемым контекстом приложения ConfigurableApplicationContext Инициализация кастомизированных фабрик с инициализацией настроек осуществляется через описание бинов в файле spring.factories

Ресерч  

В домене rbkmoney распрострена практика создания интеграционных тестов с использованием цепочки наследования классов, когда родитель является классом с конфигом теста, в которой спрятана вся техническая инициализация спрингового приложения и внешних зависимостей, которые по стандарту являются TestContainers

Класс-родитель с конфигом для тестов, для которых является необходимым использования PostgreSQL в качестве внешней зависимости:

  
@SpringBootTest
@Testcontainers
@DirtiesContext
@ContextConfiguration(classes = Application.class,
        initializers = Initializer.class)
public abstract class AbstractPostgreTestContainerConfig {

    private static final String POSTGRESQL_IMAGE_NAME = "postgres";
    private static final String POSTGRESQL_VERSION = "9.6";

    @Container
    public static final PostgreSQLContainer DB = new PostgreSQLContainer(DockerImageName
            .parse(POSTGRESQL_IMAGE_NAME)
            .withTag(POSTGRESQL_VERSION));

    public static class Initializer implements ApplicationContextInitializer<ConfigurableApplicationContext> {
        @Override
        public void initialize(ConfigurableApplicationContext configurableApplicationContext) {
            TestPropertyValues.of(
                    "spring.datasource.url=" + DB.getJdbcUrl(),
                    "spring.datasource.username=" + DB.getUsername(),
                    "spring.datasource.password=" + DB.getPassword(),
                    "flyway.url=" + DB.getJdbcUrl(),
                    "flyway.user=" + DB.getUsername(),
                    "flyway.password=" + DB.getPassword()
            ).applyTo(configurableApplicationContext);
        }
    }
}
  

К плюсам данного решения можно отнести тот факт, что сами тесты становятся более читаемым, в которых нет ничего лишнего, кроме покрытия бизнес-логики приложения

Тогда типичный тест Dao слоя будет выглядеть как:

  
class PaymentDaoTest extends AbstractPostgreTestContainerConfig {

    @Autowired
    PaymentDao paymentDao;
  
  ...

}

В этом моменте появилось желание избавиться от самого способо организации инициализации тестов с использованием порождающего класса, которая влечет повышение запутанности кода, но при этом сохранить приемлемый уровень лаконичности и простоты, свести запутанность к минимому, избавиться от наследования