True, False, Nil, NotNil и Empty: простые проверки

assert.True(t, ok) требует, чтобы ok был равен true, assert.False(t, ok) — чтобы false. На первый взгляд это дубль проверки ok == true через if, но разница проявляется при провале: if молча не выполнит ветку, а тест-функция с assert.True напишет в отчёт «Should be true» и покажет фактическое значение флага. Именно поэтому в тестах развилки if почти не живут: они проверяют вручную и молча, а тест обязан шуметь. Полезная деталь API: и True, и False принимают те же необязательные msgAndArgs, что и остальные утверждения — сообщение с контекстом («токен истёк за секунду до операции») попадёт в отчёт рядом с провалом. Частая ошибка новичка — assert.Equal(t, true, ok) вместо assert.True(t, ok): работает так же, но читается хуже и выводит более шумный diff. Инвертированные версии у каждой проверки тоже есть на месте: NotNil и NotEmpty — прямые антиподы Nil и Empty, и в паре с True/False они покрывают большинство сценариев с булевыми полями и результатами валидации.

assert.Nil(t, v) проверяет, что v — нулевое значение своего типа: nil для указателей, слайсов, карт, каналов, интерфейсов и функций, ноль для чисел, пустая строка для string, false для bool. Это шире, чем проверка v == nil: для числа 0 и строки "" Nil тоже сработает, потому что в терминах testify «нулевой» и «пустой» для примитивов означают одно и то же. Не путайте с NotNil: assert.NotNil(t, err) иногда встречается в чужих тестах вместо assert.Error, но так делать не стоит — для ошибок есть специальные проверки с более ясным выводом, они разобраны в уроке про проверку ошибок. Ещё одна привычка, которая отличает зрелый тест: проверять Nil не только на желаемые результаты, но и на то, что освобождение ресурсов обнулило указатель — так ловят использования после закрытия.

assert.Empty(t, v) отвечает на вопрос «здесь ничего полезного?» для самых разных типов: пустая строка, слайс длины ноль, пустая карта, nil того же семейства, нулевой канал, ноль числа, false. Утверждение построено на helper-функции, которая сначала пробует взять длину через отражение, а для примитивов сравнивает с нулевым значением. Отсюда практическое следствие: Empty объединяет в одной проверке то, что в чистом Go требует разных выражений — len(s) == 0, s == nil, s == "". NotEmpty — зеркальная проверка, и она особенно удобна для входных данных: assert.NotEmpty(t, resp.Items, "API обязан вернуть хотя бы один элемент") читается как требование продукта, а не как код.

Zero — родственник Empty, но с более строгой семантикой: он сравнивает значение с нулевым значением ТИПА, а не с абстрактной пустотой. assert.Zero(t, counter) после сброса счётчика читается точнее, чем Empty, потому что говорит о типовой нулевости. Для структур Zero проверяет рефлексией каждое поле — и здесь прячется нюанс: структура со всеми нулевыми полями пройдёт Zero, но структура с любым ненулевым полем провалит проверку с подробным diff. На практике Zero чаще всего встречается на числах и time.Duration, NotZero — на проверках, что что-то посчиталось: assert.NotZero(t, resp.Elapsed, "замер времени обязан быть ненулевым"). Для float-полей помните урок про сравнение чисел с плавающей точкой: Zero на аккумулированных долях лучше ставить только там, где ноль действительно точен.

Провал простой проверки информативен ровно настолько, насколько вы о нём позаботились. На Nil testify напишет ожидание nil и фактическое значение — если там спрятана структура, вывод будет многострочным. На Empty покажет тип и содержимое пустоты: строку, длину коллекции, ноль. На Zero выведет diff между нулевым значением типа и фактическим. Всё это можно и нужно снабжать сообщением: без него отчёт говорит «что», без «зачем», и через месяц после написания теста вы будете гадать, чем именно был важен этот Nil. Отдельный приём — проверять в сообщении условия, при которых проверка справедлива: «очередь пуста после Drain, но не до первого Run» — такое сообщение превращает провал в подсказку, а не в загадку.

Базовый набор собран: флаги, nil, пустота, нулевые значения — теперь можно читать чужие тесты без словаря и писать свои так, чтобы отчёт рассказывал историю сам. Следующий шаг — сообщения: у каждого утверждения testify есть необязательный хвост msgAndArgs, и умение писать его коротко и по делу отличает тест, который приятно чинить, от теста, который просто краснеет. После сообщений перейдём к сборным конструкциям — сьютам с методами подготовки, где базовые проверки будут жить уже в организованных группах. Напомню про среду: все проверки выполняются внутри go test, поэтому полный прогон — локальный Go; в браузерной песочнице вы можете потренировать заполнение пропусков и порядок строк, а запуск тестов — уже на своей машине. Общий маршрут — на странице курса по testify, а если хочется освежить, откуда берутся нулевые значения в Go, — это урок про переменные и типы базового курса.