JSONify и сравнение JSON в тестах

Сигнатура из assert/assertions.go: func JSONEq(t TestingT, expected string, actual string, msgAndArgs ...interface{}) bool. Оба аргумента — строки: JSON из файла-фикстуры, литерал в тесте или rr.Body.String() из HTTP-теста. Нормализация происходит сама: JSONEq распаковывает обе строки и сравнивает распакованное, поэтому порядок ключей, отступы и переводы строки роли не играют — сверяются данные, а не их запись. Философия та же, что в уроке про assert и require: сначала привести к каноническому виду, потом сверять. Строку-ожидание удобно держать прямо в тесте: маленький документ читается с экрана, большой живёт в файле — о файлах речь в следующем уроке. Механика у JSONEq двухступенчатая, и вторую ступень почти никто не проверял: чем именно сравниваются распакованные значения. Разберёмся сейчас.

По исходникам testify шаги такие. Сначала json.Unmarshal([]byte(expected), &expectedJSONAsInterface) в interface{}: битый JSON в ожидании — немедленный провал с сообщением про «is not valid json». Дальше шорткат: если строки совпали байт в байт, функция вернёт true, не распаковывая actual — тривиальный случай отрабатывает бесплатно. Затем Unmarshal второй строки и на финише — assert.Equal над распакованными значениями. Equal зовёт ObjectsAreEqual, а для карт и слайсов тот выполняет reflect.DeepEqual: рекурсивное сравнение структур данных. DeepEqual сравнивает карты по ключам, а не по порядку записи — отсюда и главное свойство JSONEq: переставленные ключи неразличимы, лишние пробелы исчезли при распаковке. Провал при этом рисует читаемый diff — наследие Equal. Знать механику стоит хотя бы ради следующей ловушки: во что json.Unmarshal превращает числа.

Документация encoding/json фиксирует: Unmarshal в interface{} хранит все числа как float64. Для типовых значений незаметно, но у поведения два хвоста. Первый — точность: float64 без потерь представляет целые до 2^53, значения выше — идентификаторы из систем вроде Snowflake, суммы в копейках за год — округляются, и два разных числа могут превратиться в одно. JSONEq при этом честно скажет «равно»: под ним float64 против float64, расхождение потерялось ещё при распаковке. Второй хвост — int64 не влезает в float64 вовсе: у максимального int64 младшие биты теряются всегда. Лечение по ситуации: типизированная структура с полем int64 — Unmarshal парсит его точно; json.Decoder с UseNumber — числа становятся json.Number и сравниваются без потерь. Внутри JSONEq эти пути недоступны: он зашит на дефолтный Unmarshal, и большой ID в нём потерян до всякого сравнения.

Разработчики, пришедшие из других экосистем, ищут в testify JSONContains — ассерт вида «в документе есть эти поля, остальное не важно». По исходникам assert-пакета его там нет: ни в выпусках 1.8–1.9, ни в актуальном master — функция в библиотеку так и не попала. Это не беда: подмножество проверяется штатными средствами. Распакуйте ответ в map[string]any и возьмите assert.Subset: в современных testify он умеет карту в карте — каждый ключ подмножества обязан найтись в карте и совпасть по значению, сверка идёт через тот же ObjectsAreEqual. Точечные проверки через got["id"] — тоже вариант, когда полей два-три. Для обратного требования — ключа быть не должно — есть assert.NotContains: на карте он проверяет отсутствие ключа, что удобно для паролей и токенов, просочившихся в ответ.

Когда схема ответа стабильна, честнее обойтись без any: типизированная структура ловит потерю типов — строка вместо числа не уместится в поле int, и Unmarshal вернёт ошибку. Схема знакома по уроку про сравнение структур: распаковка в структуру, дальше assert.Equal по полям. HTTP-версия этого приёма разобрана в уроке про HTTP-хендлеры. У подхода есть цена: неизвестные поля теряются молча — структура игнорирует лишнее, и тест не заметит, что ответ разросся. Если рост ответа важен, добавьте проверку количества ключей в карте или Subset поверх. Зато большие числа точны: поле int64 парсится без float64-округления, и ловушка из середины урока исчезает. Правило выбора — в таблице выше, а спор о том, что держать в тестах, — под ней.