Параллельные тесты и изоляция

t.Parallel() — маркер в теле теста: он говорит фреймворку, что тест можно приостановить и досчитать вместе с другими параллельными. Механика такая: параллельные тесты доходят до маркера и засыпают; после завершения всех последовательных тестов пакета они просыпаются и идут толпой, ограниченной флагом -parallel — по умолчанию он привязан к GOMAXPROCS машины. В выводе go test такие тесты помечены словом PAR, и по этой пометке удобно проверять, что параллельность вообще случилась. Каждый проснувшийся тест со своим контейнером получает честную изоляцию: свой Postgres, свои таблицы, свой Redis, а Docker раздаёт каждому случайный свободный порт хоста через MappedPort — конфликтов портов не будет, если не фиксировать их руками. Цена — память и старт: восемь одновременных Postgres — это восемь буферных пулов и восемь ожиданий готовности. Когда сценарий «параллельные тесты go» становится повседневностью, решение принимают по формуле: лёгкий образ — контейнер на тест без раздумий, тяжёлый — сначала попробуйте изоляцию данных на общем инстансе.

Общий контейнер стоит дешевле десятка: один старт, одна порция памяти, одно ожидание готовности. Но данные придётся развести руками, и у каждого хранилища свой механизм. В Postgres тест заводит себе схему: CREATE SCHEMA с именем от t.Name() даёт уникальное пространство имён — таблицы одного теста не видны соседям, миграции применяются внутри схемы, строки не пересекаются. В MongoDB изоляция достигается базой на тест: имя базы и коллекций строится от имени теста, дроп в Cleanup. В Redis — префикс ключей: тест пишет и читает только под своим префиксом. В Kafka и RabbitMQ — уникальные топики, обменники и очереди: имена от t.Name() или со случайным суффиксом. Бонус такого именования — отладка: по docker ps и по списку схем или топиков сразу видно, чей ресурс остался висеть после упавшего прогона. Общий принцип один: имя ресурса строится из идентификатора теста, и тогда два параллельных теста физически не могут наступить на один и тот же кусок данных.

Контейнер на тест и общий контейнер — не конкуренты, а два полюса шкалы. Первый полюс: максимум изоляции, нулевая связность, максимум памяти и стартов. Второй: один контейнер на пакет, изоляция данными, а связность появляется там, где её не ждали: общие кэши, счётчики, статусные таблицы. Миграции на общем инстансе должны быть идемпотентными и согласованными: несколько параллельных тестов, накатывающих схему в одну служебную базу, — отдельная гонка, которую снимают прогоном миграций один раз до старта тестов. Переиспользование контейнера по имени — режим Reuse из урока про переиспользование — в параллельном мире особый случай: в исходниках доступ к переиспользуемому контейнеру защищён мьютексом, и комментарий прямо называет обе причины гонки — ParallelContainers и t.Parallel. Мьютекс гарантирует, что create и start не погоняют друг друга: второй тест получит уже созданный контейнер. Но данные он не защищает: два теста в одном контейнере перезаписывают строки, сбивают счётчики и ломают ожидания друг друга. Started: true живой контейнер не перезапускает — процесс один, данные общие. Reuse — инструмент итерации над одним тестом, а не стратегия параллельного пакета.

Запускать testcontainers параллельно можно и без своих горутин: библиотека даёт функцию ParallelContainers. На вход — ParallelContainerRequest, срез обёрток GenericContainerRequest: те же декларации, что и поодиночке. Опции — ParallelContainersOptions с полем WorkersCount: ноль означает дефолт в восемь воркеров, каждый воркер — горутина, разбирающая запросы из канала. Возврат — срез контейнеров и агрегированная ошибка: ParallelContainersError хранит список ParallelContainersRequestError, по записи на неудавшийся запрос, с исходной декларацией внутри. Назначение — поднять сразу несколько зависимостей стенда: сервис, базу, брокера — и не ждать их по очереди. Результаты собираются по мере готовности, поэтому порядок в возвращённом срезе не обязан совпадать с порядком запросов — сопоставляйте контейнеры с запросами по данным, а не по индексу. Для пакета тестов этот вызов не нужен: тесты запускает фреймворк, а контейнеры заводит хелпер. Уборка остаётся на вас: TerminateContainer на каждый успешный контейнер, как и в одиночном прогоне.

Раннер — конечный ресурс, и у параллельности есть физический потолок. Память: каждый Postgres, Kafka или Mongo держит свой буферный пул, и сумма одновременных контейнеров должна влезать в RAM с запасом. Процессы: лимит pid у демона и в cgroup контейнера — не абстракция, сотни одновременных контейнеров упираются в него раньше, чем в память. Порты: Docker выдаёт случайные свободные порты сам, поэтому конфликтов нет — беда начинается только с фиксированными портами хоста. Параллелизм регулируется двумя ручками: флаг -parallel ограничивает одновременные тесты внутри пакета, WorkersCount — одновременный старт контейнеров в ParallelContainers. Сессии: каждый пакет — отдельный процесс, библиотека выводит идентификатор сессии из родительского pid, помечает контейнеры меткой org.testcontainers.sessionId и держит на сессию одного уборщика, чьё имя построено из sessionID; при параллельных процессах одной сессии спавнер ищет живого уборщика со случайными интервалами ожидания в пределах двадцати секунд, чтобы попытки не совпадали. Сессию можно зафиксировать извне переменной окружения TESTCONTAINERS_SESSION_ID или свойством session.id: все процессы с одинаковым значением попадают в одну сессию и одного уборщика — приём для сборочных систем, у которых пакеты не имеют общего родителя. Как уборщик зачищает остатки — тема урока про Ryuk.