Грабли: порты, скорость и флейки

Стартовый провал случается на трёх этажах, и этаж подсказывает сама обёртка ошибки. Create падает раньше всякого процесса приложения: опечатка в имени или теге образа, недопустимая комбинация полей декларации — Docker даже не пытался ничего запускать, и лечение начинается со сверки Image. Start падает, когда процесс умирает мгновенно: битая команда, невалидный конфиг, занятый внутри порт — тест видит обёртку start container, а настоящую причину ищут в логах контейнера. Третий этаж самый коварный: wait-стратегия ждёт порт, который никто не экспонировал. Сервис порт слушает, но в ExposedPorts его нет — библиотека честно опрашивает биндинги, не находит их и валится по таймауту ожидания; строка «port not found» означает, что маппинга не существует, а не что сервис медленный. Сюда же примыкает MappedPort до старта: у созданного, но не запущенного контейнера биндингов ещё нет, и вместо хостового порта вернётся та же ошибка. Для диагностики пригодится и логгер библиотеки: с ним в выводе теста видны шаги старта, а вместе с логами контейнера — почти весь маршрут ошибки. Порядок железный: экспонировать порт, дождаться стратегии и только потом забирать хост и порт.

Флейковые тесты go-пакетов почти всегда начинаются одинаково: контейнер стартовал, сервис ещё думает, а тест уже стучится в порт — и кто-то подставляет time.Sleep на пару секунд. Локально это работает: машина свободна, образ прогрет, сервис успевает подняться с запасом. На CI под соседними джобами те же две секунды кончаются мгновенно, и тест начинает флапать: падает без изменения кода, лечится повторным запуском и подрывает доверие к зелёному экрану. Sleep — ставка на худший из миров: слишком короткий интервал даёт флейки, слишком длинный — минуты лишнего ожидания в каждом прогоне. Отдельный соблазн — увеличивать интервал после каждого падения: цифра растёт, диагноз так и не ставится, а следующий раннер найдёт ещё более медленную машину. Лечение одно: готовность не угадывают, а наблюдают. wait-стратегия — порт, строка в логе, HTTP-проба — возвращает управление ровно тогда, когда сервис реально отвечает, а таймаут отсекает бесконечное ожидание явной ошибкой. Выбор стратегии и тонкости таймаутов разобраны в уроке об ожиданиях. Правило простое: каждое ожидание в тесте должно отвечать на вопрос «что именно я наблюдаю», а Sleep на этот вопрос не отвечает.

Параллельный прогон вскрывает грабли, невидимые на одном воркере. Фиксированный Name — ресурс в единственном экземпляре: два теста с одним именем стартуют одновременно, и второй create падает с конфликтом; имя оправдано только тогда, когда оно нужно протоколу — например, режиму Reuse. Reuse без имени падает ещё раньше: проверка стоит в самом начале GenericContainer и отклоняет пустое имя до всякого Docker. Сам режим переиспользования добавляет сюжет про грязное состояние: контейнер живёт между тестами и помнит всё, что они записали, поэтому третий тест внезапно проваливается из-за данных, оставленных первым. Общий контейнер требует дисциплины: уникальные ключи и схемы от t.Name(), TRUNCATE и FLUSHDB в Cleanup, идемпотентные миграции — приёмы разобраны в уроке про reuse и теме про параллельность. И помните: мьютекс внутри библиотеки защищает только сам запуск контейнера, но не данные внутри него. Симптом гонки коварен: локально всё зелёное, а падение появляется только на CI с несколькими воркерами — такой флейк стоит искать в общих ресурсах. Отсюда и правило диагностики: прежде чем грешить на библиотеку, воспроизведите прогон с двумя воркерами локально — большинство гонок видно и на одной машине.

Утечку обнаруживают по косвенным признакам: docker ps после прогона показывает рой контейнеров, машина заканчивает память, CI-раннер не может забрать порт. Причина всегда одна — уборка не зарегистрирована или сработала не там, где вы думали. Дисциплина простая: CleanupContainer или t.Cleanup с Terminate пишут сразу после создания контейнера, до проверки ошибки, — тогда уборка исполнится при любом исходе, включая панику и t.FailNow. Библиотека здесь на вашей стороне: Terminate не считает ошибкой «не найден» и «удаление уже идёт», поэтому дублировать уборку безопасно, а пропускать — нет. Страховочный слой — уборщик-супервизор: он помечает ресурсы служебными метками и зачищает их после смерти процесса-владельца, так что убитая джоба не оставляет зомби навсегда. Но между тестами зомби живут зря, съедая память и порты, поэтому CleanupContainer — не бюрократия, а освобождение ресурса в момент, когда он больше не нужен. Отдельный подвох — ручной defer в хелпере: параллельные горутины и defer легко расходятся по порядку, а Cleanup-функции фреймворк исполняет сам и в правильный момент. Проверка дешёвая: один взгляд на docker ps после прогона — и утечка не доедет до продакшена. Механику уборщика во всех деталях разбирает урок про Ryuk.

Скорость на CI теряется двумя способами, и первый — сеть: каждая джоба тянет образ заново, десятки секунд на каждый контейнер. Лечение — прогрев: пре-пулльте образы до go test и кэшируйте каталог Docker-данных между запусками; готовый workflow и оговорки про кэш разобраны в уроке про CI. Второй способ дороже — контейнер на каждый тест: сотня тестов даёт сотню стартов, каждый со своей wait-стратегией, своей уборкой и своим шансом флапнуть. Дешевле поднимать один контейнер на пакет в TestMain и чистить данные между тестами: пересоздание оправдано, только когда состояние принципиально нельзя сбросить — свежие миграции, расширения, конфиги с правами. Цена старта различается на порядки: образ уже на машине — секунды, образ тянется по сети — десятки секунд. Заодно выигрывает и стабильность: чем меньше стартов, тем меньше мест, где тест ловит гонку за свободный порт. Рабочее правило: сначала измерьте, сколько реально стоит старт контейнера в вашем прогоне, потом оптимизируйте. Цена замеряется просто: запустите пакет с одним тестом и с двумя и вычтите разницу — это и есть стоимость одного контейнера.