Comments 11
Я замаялся настраивать запуск TestContainers из Docker и GitLab CI/CD и заменил на Zonky.
Вот да, единственное - трудно в Gitlab настроить, т.к. ryuk требует docker.sock чтобы управлять запуском / остановкой / чисткой контейнеров. https://www.testcontainers.org/supported_docker_environment/continuous_integration/gitlab_ci/
На своём раннере ещё можно настроить. На общих гитлабовских раннерах будет сложно что-то сделать.
А скормить скрипты ликвы не пробовали? В доке вроде бы сказано, что добавили поддержку, но нет никакой информации по алгоритму действий, с flyway всё проще.
Если под ликвой имеется ввиду ликвибаза, то -
Пробовал (переезжал с h2 на тестконтейнеры, настройки не менял в части ликвибазы), скрипты накатываются, но только есть один нюанс - если использовать автоконфигурацию спринг бутовую, то при настройке тестового контекста вместо указанного (в классе с настройкой контейнера) пользователя начинает использоваться пользователь с логином system (а вот пароль остаётся тот, который указали). Тем не менее - скрипты накатываются, всё работает.
У меня не было необходимости выражать отношение depends on для контейнеров, но мне кажется это можно довольно явно выразить через ´Nested´ (см. ссылку).
Внутренний тест будет запускать после внешних тестов и после их инициализации. Можно и без Spring обойтись, в теории.
Пробовали использовать этот механизм?
Nested не пробовал. В целом стараюсь избегать любых вложенных классов, ибо большой класс, даже хорошо организованный - довольно сложно читать.
В теории да, конечно всегда можно без спринга обойтись (вопрос в том, насколько это сложно), но целью было интегрировать механизм именно в существующее спринговое приложение.
Например, в рамках следующего кейса - в спринговом приложении поднять базу, поднять систему аутентификации+подружить их между собой и начать после всего этого играться с токенами в рамках тестирования. Описанный подход как раз позволил этого добиться.
Контейнеры как бины выглядят как революционный шаг в написании тестов в тестовом контексте спринга. Данный механизм хорошо использовать если после запуска контейнера нужно с этим контейнером что-то ещё сделать. Также нужно отметить , что логику самой инициализации контейнера тоже можно дополнять, использую другие бины.
Например если в тестовом контектексте спринга вы захотите добавить кейклоак для проверки и написании сценариев с валидацией токенов и их ролей, но при старте контейнера там нет пользователей. Таким образом после старта контейнера можно запускать дополнительную логику инициализации (например создание пользователей или регенерация секрет ключа, который также можно будет положить в проперти). Примеров можно много привести.
Спасибо, конечно, за аннотацию @AutoConfigurePostgresContainer, но толк от неё будет только если выносить Ваш функционал в отдельную библиотеку. И использовать эту аннотацию как инструмент конфигурирования тестового контекста.
Spring Test Containers как бины