Хуки сьюта: SetupSuite, TearDownTest и компания

Для сьюта с двумя методами маршрут такой: SetupSuite → SetupTest → TestOne → TearDownTest → SetupTest → TestTwo → TearDownTest → TearDownSuite. Внутри метода с подтестами между SetupTest и TearDownTest укладываются пары SetupSubTest → тело → TearDownSubTest на каждый s.Run. Два свойства запомните сразу. TearDownTest гарантированно выполняется и при провале метода: testify зовёт уборку в defer, так что require-остановка или паника чистку не отменяют — то же верно и для TearDownSuite. И методы идут в алфавитном порядке: рефлексия перебирает методы по имени, а не по строкам файла, поэтому TestAdd выполнится раньше TestCreate, как бы вы ни расставили объявления. На отдельный прогон это не влияет, но вместе с мутациями полей даёт тесты, которые зелёные только в одном порядке запуска — об этом ниже.

SetupSuite — место для всего, что дорого создавать и что переживёт весь прогон: соединение с базой, миграции схемы, запуск тестового контейнера, поднятый HTTP-сервер. Результат складывается в поля сьюта, и методы видят его готовым. Граница у щедрости та же: SetupSuite выполняется один раз, и всё, что он положил в поля, делится всеми методами. Соединение делить можно и нужно, а записи в таблице — нельзя: первый же метод, создавший строку, испортит подсчёты остальным. Рабочее деление: SetupSuite — ресурсы, SetupTest — данные. Если подключение в SetupSuite не удалось, проверяйте ошибку через s.Require().NoError: провал подготовки должен красить прогон сразу, а не превращаться в панику на nil-соединении в первом методе. Тесты без базы отчитались бы десятком ложных провалов вместо одного честного.

SetupTest — самый занятой хук: перед каждым методом он восстанавливает мир. Сюда идёт пересоздание записей, чистые каталоги (s.T().TempDir() даёт путь, уникальный на тест), сброс карт и счётчиков в полях, пересоздание клиентов поверх общего соединения. Обратная сторона частоты: тяжёлые глобальные ресурсы сюда тащить не стоит — пересоздавать соединение на каждый метод значит платить за каждое открытие; им место в SetupSuite. TearDownTest — зеркальная уборка, и она честная: testify держит её в defer, так что даже require-остановка или паника внутри метода уборку не отменяет. Соль пары — изоляция: два метода не должны знать друг о друге, и любой обязан проходить в одиночку под -run. Проверка изоляции дешёвая: прогоните сьют дважды — целиком и с фильтром по одному методу. Расхождение сразу показывает метода-жильца, который живёт на чужой подготовке.

TestMain(m *testing.M) — соседний механизм с другой зоной действия: одна функция на весь пакет, а не на сьют. Точки входа go test и её жизнь в пакете разбирались ещё в уроке про первый assert: TestMain управляет запуском целиком — подготовка до m.Run(), сбор кода возврата и os.Exit после. Каркас короткий: подготовка, code := m.Run(), уборка, os.Exit(code) — всё, что объявлено до и после m.Run(), охватывает весь пакет. Тестовому контейнеру на пакет или глобальному реестру — место здесь. SetupSuite скромнее: скоуп — один сьют; в пакете их может быть несколько рядом с плоскими функциями, и хуки каждого видят только свой мир. Отсюда правило: нужда одного сьюта — хуки, нужда всего пакета — TestMain. Ошибка на обоих уровнях одинаковая — перепутать масштаб: TestMain с подготовкой под конкретный сьют заставит плоские тесты платить за чужую базу, а TestMain, забывший m.Run(), молча не запустит ни одного теста.

Шесть хуков, порядок вызовов, деление «ресурсы в SetupSuite, данные в SetupTest», мутирующие поля и границы TestMain — с этим набором сьют перестаёт быть коробкой с полями-свалками и становится расписанием. Следующая ступень курса — табличные тесты и моки: сьют с хуками — готовый контейнер для того и другого, потому что подготовка уже вынесена из методов. Если базовая механика — методы без t, точка входа, s.Run — ещё тормозит, вернитесь к основам сьютов: порядок хуков читается только поверх каркаса. Общий маршрут и соседние темы — на странице testify-курса: после сьютов идут табличные тесты, где хуки соединяются со слайсом кейсов.