Одноразовые базы данных в контейнерах для интеграционных тестов

Цель

Запускать тесты доступа к данным и интеграционные тесты на реальной СУБД, заново поднятой для прогона, чтобы выявлять особенности диалекта, ограничений и транзакций, скрытые заменой в памяти или замоканным репозиторием.

Предварительные условия

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

Шаги

1. Запускайте СУБД один раз на прогон, а не на каждый тест. Testcontainers описывает себя как средство, предоставляющее лёгкие одноразовые экземпляры баз данных в Docker-контейнерах: они запускаются из тестового кода и затем удаляются. Простой альтернативный вариант — docker run со случайным опубликованным портом, который затем считывается из среды выполнения.
2. Разместите каталог данных в монтировании tmpfs (--tmpfs при docker run) и ослабьте настройки долговечности данных СУБД для непроизводственного использования, поскольку данные одноразовые.
3. Один раз примените миграции к шаблонной базе. Документация PostgreSQL указывает, что CREATE DATABASE копирует существующую базу, поэтому CREATE DATABASE t_42 TEMPLATE t_base даёт каждому тестовому файлу свежую копию без повторного выполнения миграций. Во время копирования у исходной базы не должно быть других подключений.
4. Выберите одну стратегию изоляции и используйте её везде: новая база на каждый тестовый файл, откатываемая транзакция на каждый тест или очистка таблиц, затронутых тестом.
5. Получайте параметры подключения из работающего контейнера и передавайте их тем же путём конфигурации, который приложение использует в рабочей среде, чтобы тест охватывал и обработку конфигурации.
6. Зафиксируйте тег образа на мажорной версии, используемой в рабочей среде, и применяйте одинаковую настройку локально и в CI.

Ожидаемый результат

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

Ограничения и основания метода

Запуск добавляет секунды к каждому прогону, поэтому чистые модульные тесты стоит держать в отдельном, более быстром наборе. В документации Testcontainers повторное использование контейнера между прогонами обозначено как экспериментальная, явно включаемая возможность, не подходящая для CI. Откатываемая транзакция не позволяет проверить код, который фиксирует транзакции, использует несколько подключений или полагается на триггеры, срабатывающие при фиксации. Управляемая облачная база может отличаться от образа расширениями и параметрами; этот метод проверяет СУБД, а не управляемый сервис. Конкретные значения времени не заявляются.