Comments 14
Не пробовали PostgreSQL заменять на SQLite in-memory?
Тесты получаются не совсем "честными", зато быстро, просто и контейнеров не надо.
Sqlite имеет некоторое количество особенностей поведения. Начиная от того, что создание базы через миграции падает и заканчивая многопоточными блокировками и прочими спецэффектами даже при работе в памяти.
Кроме того, эти субд всё же разные и иногда то, что работает в одном месте, не работает в другом. Так что в интенрационных тестах лучше, на мой взгляд, использовать те зависимости, с которыми проект будет жить в проде. Тем более, что сейчас для этого и делать почти ничего не надо
Не пробовали PostgreSQL заменять на SQLite in-memory?
К сожалению, не всегда рабочий вариант, если используются фичи постгреса.
Например мы используем енамки и jsonb из него, а в паре мест вообще сырой SQL.
Конечно пробовали. Не то что "пробовали", мы еще и активно используем в юниттестах.
Но как уже справедливо заметили, sqlite это не postgres, и есть сценарии, где это критично.
Так же скулайтом нельзя заменить другие инфраструктурные штуки. Redis там, RabbitMq всякий. Тут без контейнеров будет тяжко;)
Видел где-то запускали постгрес в оперативной памяти, получается довольно быстро. Это как альтернатива sqlite
А можно сделать docker compose проект в решении и наполнить его зависимостями.
Не рассматривали такой вариант?
Вначале вы говорили о поиске альтернативы для тестового стенда на котором есть множество сервисов. Но в подходе с testcontainers описано тестирование только одного сервиса и его субд. А как быть со сценариями где требуется протестировать взаимодействие нескольких сервисов? Проект с интеграционными тестами будет отдельным приложением который в котором тестируемые сервисы конфигурируются через testcontainers или речь о подходе где в контейнерах поднимаются только out-of-process зависимости конкретного сервиса а внешние зависимости мокаются?
Сейчас мне стало немного стыдно, что мне стало лень готовить тестовый пример с пачкой зависимостей. Я бы взял на себя смелость пообещать вам вторую часть этой заметки, но кажется, что там не будет чего-то нового и особенно интересного.
Что насчет тестирования реальных многоконтейнерных приложений, то все зависит от того, что вы хотите протетсировать на самом деле. Если писать тесты сразу на все приложение, то да, все компоненты поднимаются в testcontainers и дальше идет обычная работа регрессионных тестов.
Другое дело, что те интеграционные тесты, которые лежат рядом с модульными, тестируют конкретное приложение, поэтому их задача поднять только зависимости этого приложения. А дальше - вопрос насколько вы хотите поднимать инфру, потому что у каждого компонента есть свои зависимости, а у них могут быть свои и так далее. В какой то момент придется остановиться:-)
Мне кажется, речь о немного разных видах тестах. То что вы описываете в итоговом варианте в нашей компании называется функциональными тестами. Такие тесты являются частью кода конкретного сервиса и их пишут разработчики, в отличие от unit-тестов они проверяют сервис как черный ящик, например, вызвали api и проверили результат. При этом также в докере поднимается субд и прочие out-of-memory зависимости, а зависимости внешние (другие сервисы) мокаются.
При этом у также есть e2e (интеграционные) тесты которые полноценно проверяют взаимодействие между сервисами без моков, их уже пишут тестировщики. С появлением функциональных тестов мы стали меньше писать e2e, но все же продолжаем их использовать, в ряде случаев важно проверить именно интеграцию.
За testcontainers - спасибо. Видел какой-то аналогичный проект, но этот кажется симпатичнее.
По поводу запуска тестов в CI - в github actions есть services, которые кажутся более правильным подходом (в gitlab тоже есть аналог) - https://docs.github.com/en/actions/using-containerized-services/about-service-containers
Ещё такой вопрос, с testcontainers нет такой проблеммы, что когда останавливаешь debugger, то код финализации не выполняется и после отладки остаются висящие контейнеры?
Нет, их через некоторое время уберет resource reaper - штука а-ля GC https://dotnet.testcontainers.org/api/resource-reaper/
Еще раз про интеграционное тестирование ASP.NET Core c testserver и testcontainers