Введение Теория Практика Заключение Ссылки TestContainers довольно мощная штука, почитать о том, что это такое, зачем нужно можно на оф сайте, а так же есть интересная статья на Хабре.  Традиционная настройка через junit4 (посмотреть, как это делается можно в статьях в этой статье, этой статье), а более красивая через junit5 с использованием DynamicPropertySource (можно посмотреть в данной статье) довольно удобны в том случае, когда у нас простые контейнеры, никак не связанные между собой.  Трудности возникают в том случае, когда появляется потребность провести тестирование, например, базы + очереди, нескольких очередей и т.д., в общем, когда необходимо хотим провести сложное интеграционное тестирование. Проблема состоит в том, чтобы определить последовательность старта контейнеров, динамически сформировать properties для контейнеров, которые зависят друг от друга. И в этом случае можно воспользоваться имеющимся механизмом spring-beans – dependsOn. Разбирать будем на простом примере тестовый контекст + тестконтейнер + определение параметров для подключения к БД в тестовом контексте. Spring предоставляет разные возможности для того, чтобы настроить контекст. Этим мы и воспользуемся для того чтобы: Определить Bean с контейнером Определить момент запуска контейнера Динамически заполнить «.properties» файл значениями для подключения к БД ДО того как приложение начнёт пытаться подключиться к этой самой БД И сделаем так, чтобы это вся работа выполнялась только при наличии аннотации Для достижения этих целей будет использоваться механизм BeanFactoryPostProcessor (как дань уважения Евгению Борисову ;) ), т.к. благодаря BFPP возможно взаимодействовать с BeanDefinition’ами до того, как по ним начнут строиться бины. Этот механизм как раз будет использоваться для того, чтобы задать порядок старта контейнеров. 1.       Определяем бин с контейнером Описываем класс, в котором указываем что за контейнер нам нужен: указываем image, логин, пароль, указываем порт (чтобы можно было локально приконнектиться при дебаге) 2.       Определяем момент запуска контейнера Запускать будем в PostConstruct. Затем заполним конфиг файл для подключения к бд данными из нашего контейнера.  При разрушении контеста тоже пропишем логику отключения контейнера. В итоге получится класс   3.       Теперь нам нужно сделать так, чтобы наш контейнер стартовал сам по себе во время старта контекста.  Для этого создадим аннотацию, в которой создадим поле с названием того бина, который должен зависеть от нашего контейнера, таким образом определяем порядок построения бинов.  Тут конечно можно пойти дальше, создать такое поле, которое будет принимать название бина с самим контейнером (это нужно в случае, если у нас несколько таких контейнеров). В результате получится аннотация, содержащая название бина с контейнером и название бина, который должен зависеть от этого контейнера. Таким образом получится очень гибко настроить порядок старта бинов. Это нужно, например, в случае если один контейнер настраивается такими значениями, которые формирует другой контейнер и т.п. 4.       Определим BFPP который будет работать с этой аннотацией 5.       Далее, т.к. контекст у нас тестовый – надо сделать так, чтобы тестовый контекст распознавал нашу аннотацию и делал всю нужную магию. Делается это через кастомизатор контекста, который вызывается фабрикой кастомизаторов контекста (ContextCustomizerFactory -> ContextCustomizer).  Создаём ContextCustomizerFactory, в котором читаем аннотацию и передаём в кастомизатор контекста (который будет создан на след. Шаге) Прописываем созданный класс в META-INF/spring.factories 6.       Создаём кастомизатор контекста. В котором регистрируем BFPP .  7.       Запускаем тест Разумеется, всё можно кастомизировать и добавлять свой функционал. Теперь не имеет значения какой версии junit используется в тестах, настраиваются контейнеры одинаково. Было рассмотрено: Кастомизация тестового контекста через ContextCustomizer Взаимодействие с BeanDefinition’ами на раннем этапе инициализации этого контекста Реализация аннотации и взаимодействия тестового контекста с этой аннотацией Представленный функционал позволяет покрыть тестами более широкую интеграционную часть приложения, что увеличивает качество кода и снижает количество ошибок, которые возникают при регресс тестировании и которые связанны с интеграционной частью. Что такое тестконтейнер Интеграционные тесты баз данных с помощью Spring Boot и Testcontainers Как собрать образ Oracle DB для Testcontainers Интеграционное тестирование в SpringBoot с TestContainers-стартером Обзор модульного и интеграционного тестирования Spring Boot Интеграционные тесты баз данных с помощью Spring Boot и Testcontainers Мой репозиторий с настроенным spring bean testcontainer'ом   Java-разработчик