Что поднимается с помощью тест контейнеров
Что проверяют
Знаете ли вы, что именно поднимает библиотека и зачем это нужно, если есть база в памяти. Ответ показывает, писали ли вы интеграционные тесты на настоящей инфраструктуре или ограничивались юнитами с заглушками.
Как отвечать
Поднимаются настоящие зависимости сервиса в контейнерах, на время прогона тестов и с удалением после него. Обычно это:
- базы данных: PostgreSQL, MySQL, Oracle, MongoDB, вместе с накаткой миграций Flyway или Liquibase;
- очереди и брокеры: Kafka, RabbitMQ;
- кэш и поиск: Redis, Elasticsearch или OpenSearch;
- объектное хранилище и эмуляторы облака, сервер авторизации, заглушки внешних API;
- браузер для UI-тестов, а через универсальный контейнер вообще любой образ, включая собственный образ приложения для проверки чёрным ящиком.
Дальше покажите механику: контейнер объявляется в тесте, порт назначается свободный и случайный, а фактический адрес подставляется в настройки приложения динамически, в Spring это делается источником динамических свойств. Готовность ждут стратегией ожидания: строка в логе, открытый порт, проверка здоровья. Служебный контейнер прибирает за прогоном, даже если тесты упали.
Смысл в том, что проверяется тот же движок, что в бою: диалект SQL, типы, транзакции, блокировки и миграции ведут себя одинаково.
Где спотыкаются
Поднимают контейнер на каждый тестовый метод. Прогон растягивается на минуты, и команда начинает отключать тесты. Контейнер объявляют статическим на класс или общим на модуль, а данные между тестами откатывают транзакцией либо чистят явно.
Второе: заменяют базу встроенной ради скорости. Тесты зеленеют на диалекте, которого в продакшене нет, и всё интересное, от оконных функций до поведения при конкурентном обновлении, остаётся непроверенным.
Третье: забывают про среду выполнения. Библиотеке нужен доступ к демону контейнеров, на части сборочных агентов его нет или он спрятан за особым сокетом, а образы надо откуда-то тянуть. Это решается заранее, а не падением сборки в день релиза.