Testify и стандартная библиотека: границы

Снимем налёт магии. Файлы с тестами компилирует и запускает go test из стандартного пакета testing — testify в этом не участвует: он находит функции TestXxx(t testing.T), строит дерево сабтестов через t.Run — ровно так устроены [табличные тесты](/courses/testify/lessons/13-tablichnye-testy/) — и фильтрует их флагом -run по имени, с наклонной чертой для вложенности. t.Helper помечает функцию помощником, чтобы при провале в отчёте стояла строка места вызова, а не внутренности хелпера. Ассерты testify принимают первым аргументом TestingT — интерфейс самой testify с единственным методом Errorf, и testing.T ему послушно удовлетворяет. На этом роль testify кончается: он не умеет запускать тесты, не знает про кэш, профили и -race, отчёт собирает не он. Зато он экономит то, ради чего его берут, — строки проверок.

Первый район, где testify не нужен вообще: бенчмарки. Функция BenchmarkXxx(b testing.B) обязана гонять целевой код b.N раз, а само число b.N подбирает движок: начинает с одной итерации и увеличивает от прогона к прогону, пока замер не станет надёжным. Результат бенчмарка — наносекунды на операцию, аллокации, пропускная способность; проверять там нечего, кроме того, что код не паникует. Вставить assert технически можно — testing.B тоже имеет Errorf и формально подходит под TestingT, — но каждая проверка попадёт внутрь замера и соврёт в отчёте. Провал в бенчмарке честнее выражать b.Fatal: упал, зафиксировал, замер не состоялся. Запускается всё это не testify, а go test -bench=. с -benchmem для аллокаций — та же стандартная машина, никаких новых зависимостей.

Фаззинг живёт в стандартном тестировании go с версии 1.18: функция FuzzXxx(f testing.F), f.Add сеет стартовые входы, а f.Fuzz принимает цель вида func(t testing.T, in []byte). Дальше движок генерирует входы сам и валит цель, пока не найдёт провал. Ловушка новичка — тащить сюда привычный паттерн testify «ожидаю конкретный результат»: у фаззинга нет фиксированного want, каждый вход свой, и оракул приходится выводить из самого входа — инварианты, симметрии, отсутствие паники. Assert внутри цели компилируется: t там настоящий *testing.T. Но провал assert.Equal на сгенерированном входе — это простыня diff, по которой ничего не понять: эталона-то не было. Найденный контрпример движок сохраняет в testdata/fuzz/FuzzXxx/, и с тех пор он гоняется обычным go test как регрессия.

Второй район — жизненный цикл теста, где testify просто не участвует. t.Cleanup регистрирует функцию, которая отработает по завершении теста и всех его сабтестов, причём в порядке LIFO: последний зарегистрированный — первый на выходе. Это удобнее defer, когда ресурс открывает функция-помощник: она же вешает очистку, а вызывающий ничего не обязан помнить. t.Parallel помечает сабтест параллельным: такие тесты приостанавливаются, дожидаются конца последовательных и возобновляются уже вместе, каждый в своей горутине. Какие гонки это порождает — тема урока про горутины и живого места ниже. testify на оба механизма не влияет: cleanup и параллельность работают в любом проекте, включая проект без единой внешней зависимости.

Там, где проверок много, testify платит за себя строками и отчётом. assert.Equal вместо связки if !reflect.DeepEqual плюс t.Errorf — одна строка вместо четырёх, а в отчёте при провале появляется diff: testify печатает ожидаемое и фактическое построчно, пока stdlib отдаст два слепка структуры подряд. Ошибки сравниваются ErrorsIs и ErrorAs — механика ранних уроков курса. Дальше идёт то, чего в stdlib нет вовсе: моки на mock.Mock с ожиданиями и сверкой вызовов и suite с общим SetupTest на группу тестов — это разобрано в уроке про suite. Стандартное тестирование go закрывает запуск, жизненный цикл и замеры; testify закрывает формулировку проверок и подмену зависимостей. Ссорить их — ошибка планирования, а не вкуса.