Testify и TestMain: фикстуры пакета

Testify suite — это структура, встраивающая suite.Suite: тесты становятся методами с префиксом Test, а библиотека прогоняет их через фиксированные хуки. Общие ресурсы объявляются полями: контейнер, пул соединений, готовые клиенты репозиториев — каждый метод видит их как s.pool, без глобальных переменных и передачи аргументов. Внутри SetupSuite поднимают тяжёлое: postgres.Run из модуля создаёт контейнер один раз на весь прогон, дёргать Docker на каждый тест не нужно — на пакете из десятков тестов это разница в минуты. Ошибку подъёма проверяют через s.Require().NoError: падение хука помечает suite проваленным, и методы не стартуют вовсе. Один провал при этом не хоронит соседей: упавший метод помечается, а остальные исполняются дальше — со свежим SetupTest. Тут же зовут testcontainers.CleanupContainer(s.T(), ctr) — регистрация на общем T сработает в конце suite.Run при любом исходе. Доступ к текущему тесту даёт s.T(): это тот самый *testing.T, с которым работают t.Cleanup, t.Helper и t.Parallel. Запуск — suite.Run(t, new(BookingsSuite)): Test-методы библиотека находит рефлексией, а методы-помощники без префикса Test игнорирует — их зовут руками из тестов. Так suite собирает связанные сценарии в одну страницу отчёта: имена методов читаются как главы одного раздела.

Хуков у suite больше двух, и путаница между ними — источник флаки. SetupSuite исполняется один раз на прогон: контейнеры, пул, миграции схемы — всё, что дорого и не меняется от теста к тесту. SetupTest и TearDownTest обрамляют каждый метод: сюда уходит чистка состояния — TRUNCATE таблиц, FLUSHALL в Redis, сброс последовательностей идентификаторов. Тесты обязаны стартовать с одинаковым состоянием, иначе порядок исполнения начнёт влиять на результат, и классическое «зелёное локально, красное на CI» станет нормой пакета. BeforeTest и AfterTest получают имена suite и теста — удобное место для логов и метрик по методам. Полный порядок исполнения легко запомнить как матрёшку: внешний хук один, внутренние — на каждый метод, и внешние не повторяются. Общий ресурс из поля suite нельзя мутировать по мелочи в методах: методы внутри suite исполняются последовательно, но каждый получает ту же базу, что и предыдущий, а с t.Parallel внутри — уйдут одновременно и подерутся за одни таблицы. Изоляция данных и портов между параллельными прогонами — тема урока о параллельности, а здесь держим простое правило: фикстуры — в хуках, состояние — чистым на входе каждого метода. Так пакет выдерживает и добавление новых методов, и перестановку старых без правок фикстур.

Чистое состояние — главный контракт suite: каждый метод стартует с одинаковыми данными, и падение одного теста не портит соседей. Для базы это TRUNCATE с RESTART IDENTITY: счётчики сбрасываются, ссылки между таблицами не мешают; для Redis — FLUSHALL; для очередей — опустошение перед прогоном; монго-коллекции чистят удалением документов, сохраняя индексы. Чистка живёт в SetupTest, а не в TearDownSuite: убирать после себя бесполезно, если упавший тест оставил мусор посреди пакета — следующий метод унаследует грязную базу и упадёт каскадом, уведя разбор в сторону от настоящей причины. Для Redis-пула параллельно живут префиксы ключей: чистка через FLUSHALL дешевле, но опаснее при общем инстансе. Ускорение — чистить только затронутые таблицы, а не всю схему: TRUNCATE трёх таблиц заметно дешевле пересоздания базы. Хелпер чистки оформляют методом suite с t.Helper внутри, чтобы номер строки падения указывал на тест, а не на хелпер. Справочные данные, общие для всех методов — словари, справочники, константы каталога, — сеют один раз в SetupSuite: они read-only, и пересеивать их на каждом тесте — выброшенные секунды прогона. Драйвер pgx для такого пула разобран в отдельном курсе.

Почему CleanupContainer удобнее ручного defer ctr.Terminate(ctx)? Первое: он nil-безопасен — вызов сразу после создания, ещё до проверки ошибки, не паникует: nil-контейнер для него no-op. Второе: внутри он зовёт tb.Helper и tb.Cleanup — Terminate регистрируется рядом с контейнером и исполняется при любом исходе прогона: провале ассертов, t.FailNow и панике. Третье и главное — уборка умная: TerminateContainer под капотом проглатывает безопасные ошибки — контейнер уже удалён, удаление уже идёт, ресурс не найден, — и require.NoError внутри срабатывает только на настоящие проблемы. Ручной defer, который честно проверяет ошибку Terminate, уронит тест на «уже остановлен» — классическая грабля двойной уборки, когда Cleanup уже сработал, а defer ещё жив. Четвёртое: сигнатура принимает testing.TB, поэтому одна и та же строка работает в обычном тесте, в бенчмарке и в s.T() из suite. Наконец, обёртка избавляет от сложной ветки при досрочном выходе: провал посреди хука не перепрыгивает регистрацию — она уже случилась. Для сетей есть симметричный CleanupNetwork. Остатки после смерти процесса зачищает супервизор из урока про Ryuk.

Ассерты в suite живут в двух формах: пакеты require и assert напрямую или методы s.Require() и s.Assert(), которые suite раздаёт от тех же пакетов. Разница принципиальна: require при провале вызывает FailNow и останавливает тест немедленно, assert лишь помечает провал и продолжает исполнение. На пути к фикстурам выбирают require: ошибка подключения к базе не должна вести код дальше к nil-пулу — паника размажет настоящую причину по стектрейсу. Ассерты результата берут assert'ом, когда после провала безопасно дособрать остальные проверки: за один прогон соберётся список всех расхождений, а не первый попавшийся. В хуках выбор сделан за вас: там, где ошибка обрывает дальнейший путь, require — единственный безопасный вариант. Собственные хелперы помечают t.Helper: строки падения укажут на вызов в тесте, а не на тело хелпера. Внутри методов suite require и assert доступны и без импорта пакетов — через поля структуры, и это держит файлы тестов короткими. Выбор между формами — вопрос вкуса, но в одном файле его держат единым: смешение s.Require и require из пакета путает читателя.