assert и require: когда тест должен падать сразу

Снаружи пакеты близнецы: у обоих есть Equal, NoError, NotNil и весь остальной набор, сигнатуры совпадают до символа — сначала t, потом ожидаемое значение, потом фактическое. Отличие спрятано в том, что функция вызывает при провале. assert.Equal при неудаче вызывает t.Errorf: тест помечается проваленным, но выполнение идёт дальше — следующие проверки выполняются, и отчёт собирает все красные строки за один прогон. require.Equal при той же неудаче вызывает t.FailNow: текущая тест-функция останавливается немедленно, всё, что написано после, не выполняется, а тест падает с единственным сообщением. Никакой магии внутри: require — тонкая обёртка над assert, которая после проваленной проверки дёргает FailNow. Отсюда два практических вывода. Мигрировать между пакетами — значит поменять один импорт. И если тест вдруг начал обрываться на середине без видимой причины, первым делом проверьте, не сменили ли вы в нём assert на require.

FailNow — метод стандартного testing.T, testify его не изобретал: пакет require вызывает то, что фреймворк предлагает из коробки. Сначала вызов помечает тест проваленным — статус такой же, как у t.Errorf. Затем останавливает текущую тест-функцию через runtime.Goexit: горутина теста завершается, отложенные defer успевают отработать, а фреймворк переходит к следующей тест-функции пакета. Важная деталь: останавливается ровно одна функция. Провал require в TestParseUser не отменяет TestParseConfig и остальных соседей — их отчёт собирается целиком. Для require в Go-тестах это и делает предусловия осмысленными: сломанная подготовка выключает текущий тест, не трогая остальные. Ещё одна деталь, отличающая require: его TestingT требует от t не только Errorf, но и FailNow — *testing.T подходит, а произвольный тип с одним Errorf, который assert принимает охотно, require уже не устроит. Для обычных тестов разницы нет, но она всплывает в генераторах и обёртках над t.

Из двух судеб провала вырастает рабочее правило, которое в командах звучит почти как мантра: require — для подготовки, assert — для проверок. Пока тест готовит данные — создаёт сервис, делает запрос, парсит ответ — любой провал делает бессмысленным всё, что дальше: проверять поля структуры, которой нет, мы уже пробовали выше. Поэтому каждое предусловие закрывается require: require.NoError на ошибке, require.NotNil на указателе, require.Len на слайсе, если проверки завязаны на его размер. Как только подготовка закончилась, наступает очередь assert: сами проверки результата живут в нём, и провал любой из них не прячет остальные — один прогон показывает все расхождения сразу. Для функции, возвращающей структуру с полями, картина типовая: две require-строки предусловий, затем пачка assert-строк по полям. Если подготовка состоит из одного шага, а проверок всего две, разницы вы не заметите — правило экономит время на тестах, где шагов больше.

У FailNow есть жёсткое ограничение, о котором документация предупреждает прямо: вызывать его можно только из горутины, которая запускает тест-функцию. Фреймворк считает текущим тестом лишь главный поток — require, вызванный из запущенной вами горутины, вызовет FailNow там, и завершится сама горутина, а тест продолжит работать, как ни в чём не бывало. Хуже того: если тест ждал эту горутину по каналу, он может зависнуть навсегда, и go test закончится по глобальному таймауту с невнятной диагностикой вместо провала. assert из горутин вызывать можно: t.Error, на котором он построен, безопасен для конкурентных вызовов из любого числа горутин. Практичная схема — рабочие горутины только производят данные, а проверки живут в главном потоке после синхронизации. Если провал нужно зафиксировать внутри горутины, используйте assert и доведите горутину до конца: defer wg.Done() или закрытие канала.

Каркас с предусловиями — половина пайплайна; вторая половина — что именно проверять, когда функция возвращает ошибку. Это тема следующего урока про assert.NoError, EqualError и ErrorIs: там же разберём, почему assert.Equal на обёрнутых ошибках подводит. Чтобы закрепить этот урок, прогоните примеры локальным go test: закомментируйте require.NotNil в каркасе TestGetUser и посмотрите, как паника переписывает отчёт — увидеть это своими глазами полезнее любых слов. Проверки не заканчиваются на Equal: у него внутри reflect.DeepEqual, и тонкости сравнения структур со вложенными полями разобраны в уроке про сравнение структур и слайсов. Полный маршрут курса — на странице testify-курса.