msgAndArgs: свои сообщения в проверках

Любая проверка testify выглядит как assert.Equal(t, expected, actual, msgAndArgs...), и хвост собирается по простым правилам. Первый элемент — сообщение: строка или форматная строка с глаголами %s и %d. Остальные элементы — аргументы для Sprintf: assert.Equal(t, got, want, "порт из окружения %q", envName) подставит имя переменной в отчёт. Передали строку без аргументов — она выводится без форматирования. Полезно знать и про особые значения: первый аргумент хвоста, будучи nil, игнорируется (историческая совместимость с assert.Conditions), но полагаться на это не стоит — в боевом коде хвост либо осмысленный, либо его нет. Аргументы формата экономят на лишних склейках: не нужно заранее собирать строку fmt.Sprintf, testify делает это только при провале — проверки с сообщениями не тратят форматирование на счастливом пути.

Под каждой проверкой testify стоят две функции пакета testing, и testify открывает их через assert.Fail(t, failureMessage, msgAndArgs...) и require.FailNow. Fail помечает тест проваленным и продолжает выполнение — как assert с несбывшимся условием, только без сравнения вовсе: вы сами решаете, что провал случился. Это удобно для недостижимых веток: default в разборе типа, который вы считаете полным, — assert.Fail(t, "неожиданный тип события: %T", evt) фиксирует, что мир изменился. FailNow из require-пакета делает то же, но немедленно останавливает тест: правило из урока про assert и require в чистом виде — подготовка не удалась, продолжать бессмысленно. Дымовые тесты «объект собирается без паники» собираются на связке require.NoError и Fail: меньше условий — меньше мест, где тест врёт.

Как только проверка заворачивается во вспомогательную функцию — assertSessionActive(t, s) — отчёт начинает врать адресами: строка провала указывает на helper, а не на тест. Приём стандартной библиотеки: в начале helper вызовите t.Helper(), и тест-раннер будет пропускать эту функцию в стеке провалов. Внутри helper сообщение работает по тем же правилам, но его роль выше: helper переиспользуется в десятках тестов, и сообщение — единственное место, где написано, что именно он гарантирует. Комбинация из t.Helper() и хвоста msgAndArgs делает свои ассерты почти полноценными: assertSessionActive(t, s) при провале покажет и требование, и фактическое состояние сессии — без дублирования кода по файлу. Побочный бонус: Require-версия helper обязана вызываться из потока теста, о чём напомнит паника FailNow, если helper начнут звать из горутин.

Хвост — не обязанность, а инструмент, и у него есть обратная сторона. Equal на простых числах уже показывает «expected 8080, actual 9090» — сообщение «порты не равны» добавляет шум, а не смысл. Правило экономное: сообщение ставится там, где провал не объясняется diff-ом — инварианты порядка, условия после Prepare, проверки контрактов, гипотезы о причине. На цепочке проверок одного объекта сообщение обычно несёт первое звено (подготовка), дальше diff говорит сам. Отдельный случай — сообщения, дублирующие имя теста: TestServerPort_Defaults already says everything, и хвост «проверяем порт по умолчанию» пересказывает заголовок. Экономия — не скупость: отчёты с десятью повторными строками читают реже, чем отчёты с одной точной подсказкой в нужном месте. Хорошее сообщение — требование продукта или гипотеза о причине («заморозка тарифа за 3 дня до списания ломает расчёт»); плохое — пересказ диффа («actual is not equal to expected»), который и так выведен, — его лучше опустить вместе с хвостом.

Раз аргументы прогоняются через fmt.Sprintf, в сообщениях работает весь арсенал глаголов Go, и пара из них создана как будто для тестовых отчётов. %q печатает строку в кавычках — идеально для имён переменных окружения и конфигурационных ключей, где важно видеть границы. %T выводит тип значения — незаменим в сообщениях о неожиданных типах: "неожиданный тип события: %T". %v остаётся универсальным принтером структур: в хвосте он полезен в конце сообщения, когда хотите показать весь объект — но с осторожностью: большие структуры раздуют отчёт, и diff Equal уже покажет их красивее. %d для счётчиков, %s для текстов — обычная работа. Практическое правило по объёму: одна-две подстановки в сообщении, иначе сообщение превращается в дамп, который читают реже, чем сам diff.

В табличных тестах (слайс кейсов, цикл, t.Run — им будет посвящён отдельный урок дальше по курсу) хвост msgAndArgs получает ещё одну роль: идентификация кейса. Слайс кейсов крутится в цикле, и провал внутри t.Run показывает имя подтеста — но если кейсы короткие, полезно продублировать суть в сообщении: assert.Equal(t, tc.want, got, "кейс %q: ожидаем %d", tc.name, tc.want). Такой хвост объединяет в отчёте имя кейса, ожидание и факт — не нужно прыгать к объявлению структуры кейса. Обратная сторона — дублирование: если имя кейса уже показывается в заголовке t.Run, повторять его в сообщении стоит только тогда, когда само сообщение добавляет смысл — ожидаемое значение, источник, гипотезу. Баланс тот же, что и везде: сообщение отвечает на «что проверить и почему», заголовок — на «какой это кейс».

Хвост msgAndArgs разложен: строка и аргументы через Sprintf, Fail и FailNow как атомы провала, t.Helper() для своих ассертов. Дальше объём тестов начинает расти, и их надо организовывать: сьюты из пакета suite собирают группу тестов одного модуля со структурой-состоянием и методами подготовки. Там сообщения из этого урока встретятся с хуками — и окажется, что требование «после Drain очередь пуста» удобнее всего держать именно в хелпере сьют-структуры. Напомню про среду: сообщения видны в выводе go test на локальном Go — песочница здесь не заменит прогон, но потренировать пропуски и порядок строк можно прямо на странице. Общий маршрут — на странице курса по testify, а про форматирование строк в Go — в уроке про fmt базового курса.