Валидация миграций flyway c помощью testcontainers

Ранее мы уже упоминали о необходимости контроля версий БД и применения миграций с помощью инструмента Flyway и даже реализовали функционал валидации миграций в бесплатной (community edition) версии. Но мир не стоит на месте и с каждым днем появляются новые варианты решения проблем - в данной статье рассмотрим валидацию миграций flyway с помощью testcontainers. Давайте разберемся!

Тestcontainers идеально подходят для выполнения интеграционных тестов, в том числе DAL (data access layer), следовательно ничего не мешает нам использовать их для проверки миграций flyway.

Считаем, что у нас Java-проект, который собирается Gradle‘ом. Структура проекта для исходных кодов и ресурсов стандартная, включающая в себя каталоги:

• src/main/java
• src/main/resources
• src/test/java
• src/test/resources

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

Файл конфигурации проекта написан на языке kotlin и выглядит следующим образом:

В каталоге с ресурсами находится init-скрипт:

И сами миграции, разложенные по каталогам соответствующим именам БД. Пример некоторых миграций:

Основная “магия” происходит здесь:

Как видим, для начала создается PostgreSQL контейнер с заданными параметрами:

...
    private static PostgreSQLContainer container = new PostgreSQLContainer<>(DOCKER_IMAGE)
            .withDatabaseName(DB_NAME)
            .withUsername(USERNAME)
            .withPassword(PASSWORD)
            .withInitScript(INIT_SCRIPT_PATH);
...

после чего он используется в двух тестах (валидации миграций на две БД):

    public void runDB1Migrations() {
        container.withDatabaseName("database_01");
        var flyway = Flyway.configure()
                .locations("migrations/database_01/")
                .schemas("public")
                .dataSource(container.getJdbcUrl(), container.getUsername(), container.getPassword())
                .load();
        flyway.info();
        flyway.migrate();
    }

Тесты между собой отличаются только конфигураций flyway (путь к миграциям - locations("migrations/database_01/")) и переключением на нужную БД в контейнере - container.withDatabaseName("database_01");

Если все сделано правильно, то после запуска в консоли команды:

./gradlew test --info

Можно увидеть примерно следующий результат:

Далее можно “закоммитить” контейнер с уже примененнными миграциями и использовать новый образ в других тестах - если миграций много и количество тестов исчисляется сотнями, можно существенно ускорить процесс тестирования - но об этом уже в отдельной статье.

Еще, как вариант, после валидации и применения flyway миграций можно использовать JOOQ (Java Object Oriented Querying) - open source инструмент с кодогенерацией для работы с SQL в Java, который из коробки предоставляет удобный DSL для составления запросов, а также генератор классов на основе метаданных ДБ.

На этом все, полный пример валидации миграций с помощью flyway и testcontainers можно посмотреть здесь.