Тестирование с GORM — SQLite in-memory, транзакционные тесты и фабрики данных

Слой данных — самый обманчиво надёжный код в приложении: он не мигает на экране, не отвечает роутами, но именно он первым ломается от кривого WHERE, забытого фильтра или дубля по уникальному полю. Тестирование gorm начинается с честного списка того, что вообще стоит проверять: контракты методов репозитория (создал — прочитал обратно), поведение на пустой базе, фильтры и сортировки, уникальные ограничения, счётчик затронутых строк, ошибки на некорректных данных. Заметьте: ничего из этого нельзя проверить, не исполнив настоящий SQL, — GORM не эмулирует базу, Statement собирается в текст запроса и уезжает в СУБД через диалектор. Поэтому подход здесь не юнит-в-изоляции, а интеграционный: настоящая база, пусть и in-memory. На пирамиде из урока про тестирование Go это выглядит так: снизу — быстрые тесты репозитория на SQLite в памяти (их десятки, они исполняются за миллисекунды), выше — тесты сервисов и хендлеров, где репозиторий подменён интерфейсом-моком, и лишь на вершине — немного интеграционных прогонов на настоящем Postgres. Репозиторий в этой картине — шов, точка подмены: он объявляет интерфейс, его реализация гоняет настоящий GORM, а потребители тестируются на подделке. Так вы получаете и скорость, и честность там, где она нужна. Табличные тесты — t.Run-сабтесты, t.Fatal на подготовке — приезжают сюда из курса Go-advanced без изменений: поменяется только то, что вместо чистой функции на входе у вас база со схемой, а шагов стало больше: открыть, мигрировать, наполнить, проверить, убрать за собой. Последние три шага и есть герои этого урока.

Ловушка прошлого урока пересобирается для тестов одной фразой: приватная in-memory-база SQLite живёт на соединении, а у database/sql пул соединений. Открываете gorm.Open(sqlite.Open(":memory:")) без ограничений — пул заводит несколько соединений, AutoMigrate строит таблицы на первом, а второй тест, взявший второе соединение, получает пустую базу и «no such table». Прошлый урок показал лечение file::memory:?cache=shared — общая память для всех соединений пула. Но у тестирования свой вопрос: не «как заставить работать», а «какая граница изоляции нужна». Вариант первый — база на тест: каждый тест открывает собственный gorm.Open, а пул жёстко ограничивается одним соединением вызовом SetMaxOpenConns(1). Один тест = одно соединение = одна приватная база: пустая база невозможна по построению, тесты не видят чужих данных даже при t.Parallel, а стоимость — десяток лишних AutoMigrate, которые SQLite в памяти исполняет за миллисекунды. Вариант второй — база на пакет: TestMain открывает одну общую базу тем же приёмом, миграция выполняется один раз, все тесты живут в ней. Это быстрее и экономнее для тяжёлых схем, но данные перетекают между тестами: каждый тест обязан чистить за собой или работать в транзакции, а t.Parallel поверх общей базы превращается в гонку. Рабочее правило: база на тест — по умолчанию, база на пакет — осознанный выбор для дорогих схем, и тогда транзакционные тесты (ниже) возвращают изоляцию. Запрос «sqlite тесты go» почти всегда разрешается именно решением этого выбора, а не хитрыми запросами.

Схема в тестах — отдельная тема с собственным компромиссом. В тестовой базе её собирает AutoMigrate из тех же моделей, что работают в бою: одна команда — и в памяти есть таблица со всеми колонками, уникальностями и индексами из тегов. Для in-memory-SQLite это мгновенно, поэтому вызов на каждый тест — не расточительство, а источник изоляции: база свежая, как утренний снег. Честная обратная сторона: тестовая схема и боевая могут разойтись. AutoMigrate создаёт и правит, но не удаляет колонки, а настоящие боевые переходы — это миграции четвёртого урока с их версиями и фиксациями; схема, собранная AutoMigrate-ом, доказывает, что модели корректны, но не доказывает, что боевая миграция накатила ровно то же самое. Практичный компромисс: тесты репозитория живут на AutoMigrate-схеме — им важны модели, фильтры и ограничения, а отдельный тест-на-схему (один на проект) проверяет реальные SQL-миграции на настоящей базе в CI. Второй урок этой темы — не бойтесь того, что тег уникальности в модели влияет на тесты: он и должен. Тег unique на Slug создаёт уникальное ограничение — и тест дубля получает настоящую ошибку от настоящей базы, а не от вашей фантазии. Именно поэтому моки бессильны в слое данных: ограничение живёт в базе, и только база может его охранять. Итог раздела: AutoMigrate на тест-БД — это не «миграции в тестах», а способ получить честную схему за миллисекунды, оставив настоящую миграционную дисциплину боевой инфраструктуре.

Идея транзакционных тестов проста до аскетизма и красива как следствие архитектуры GORM: оберните каждый тест в транзакцию и откатите её после. Механику Begin и Rollback вы знаете из пятнадцатого урока; здесь она превращается в инструмент изоляции. Тест открывает транзакцию, репозиторий и фабрики работают с ней — а точнее, с тем же gorm.DB: метод Begin возвращает именно gorm.DB, поэтому NewTodoItemRepo(tx) и makeTask(t, tx, ...) даже не замечают подмены. Все записи теста живут внутри транзакции, непрошенные для остальных соединений, а в конце теста Rollback стирает всё разом — не нужно чистить таблицы DELETE-ами, не нужно помнить порядок удаления из-за внешних ключей, не нужно пересоздавать схему. Изоляция даром. Обратная сторона честности ради: транзакционный тест никогда не завершится Commit-ом — это нормально, откат здесь не ошибка, а цель. И вторая грань: данные, созданные внутри транзакции, видны только в ней; если код тестируемого метода сам лезет в другую транзакцию или другой пул соединений, он чужих записей не увидит — и это уже не баг теста, а свойство транзакционной модели, которое стоит знать заранее. Схема «транзакция на тест» красиво сочетается с базой на пакет: общая in-memory-база остаётся, но каждый тест существует в собственном пузыре и оставляет после себя пустоту. Именно так транзакционные тесты реабилитируют вариант «на пакет», лишая его главного недостатка — перетекания данных.

Два метода testing.T держат весь этот каркас, и оба вы разобрали в шестнадцатом уроке go-advanced — здесь они работают на данные. t.Helper() помечает функцию как помощника: если openTestDB или newTx упадут с t.Fatal, ошибка в отчёте будет указывать на строку теста, вызвавшего хелпер, а не на строку внутри хелпера — при двадцати тестах на одном хелпере разница между «читать отчёт» и «гадать» становится наглядной. t.Cleanup регистрирует уборку, которая сработает после завершения теста — включая случаи t.Fatal и t.Skip — и в порядке LIFO: последняя зарегистрированная уборка выполнится первой. Именно LIFO-порядок даёт правильную гигиену данных: newTx регистрирует Rollback раньше, openTestDB — Close, значит при завершении теста сначала откатится транзакция (транзакция ещё держит соединение — и правильно), а затем закроется база. Поменяйте порядок на бумаге — и увидите, что обратная последовательность попыталась бы закрыть базу под живой транзакцией. Есть и третья связка, о которой стоит помнить уже сейчас: t.Parallel. Тесты с базой на тест параллелятся бесплатно (t.Parallel()) — у каждого своя приватная in-memory-база; тесты на общей базе пакета параллелить нельзя без транзакционного пузыря и продуманных уникальных ключей. И маленькая привычка из того же урока: t.Fatal на подготовке (открыли базу — проверили ошибку), t.Error на ожиданиях, чтобы один сломанный тест не хоронил отчёт целиком. Хелперы, уборка, параллель — три букваря, на которых тестирование gorm стоит не хуже любого другого Go-кода.

Фабрика данных — это функция-конструктор, которая делает три вещи: задаёт осмысленные дефолты, создаёт запись в базе и возвращает её. Выигрыш виден в тесте сразу: этап подготовки (arrange) сжимается до makeTask(t, tx, "Купить хлеб") — тест декларирует только то, чем ситуация отличается от нормы, а не всю механику конструирования структуры с пятью полями. Дефолты — сердце фабрики: осмысленный Title, уникальный Slug, Done равный false; всё, что тесту важно, он переопределяет модификатором func(*TodoItem) — вариативная функция с замыканием, как makeTaskDue, который приклеивает дедлайн. Так не появляется десятка фабрик makeTaskWithDeadline, makeTaskDone, makeTaskUrgent — появляется одна фабрика и точечные варианты. Второе правило — уникальность там, где её требует схема: Slug генерируется счётчиком, потому что уникальное ограничение из тега непреклонно, и второй одинаковый дефолт в общем прогоне упал бы с ошибкой дубля — предсказуемость важнее хитростей. Третье правило — детерминизм: никакого time.Now() внутри фабрик. Тест, сортирующий по Deadline, обязан давать один и тот же порядок сегодня, ночью и в CI в другом часовом поясе; фиксированная точка fixedNow превращает время из лотереи в константу. Фабрики живут в файле вида factories_test.go рядом с тестами и переиспользуются всеми тестами пакета. И заметьте, как складывается цепочка: хелпер открывает базу, newTx накрывает тест транзакцией, фабрика наполняет её — и весь этот конвейер держится на t.Helper и t.Cleanup, о которых шла речь выше.

Самый частый спор вокруг тестирования gorm — мокать или не мокать, и здесь уместно честное мнение вместо дипломатии. Моки оправданы выше слоя данных: тест сервиса или хендлера мокает интерфейс репозитория — это быстро, стабильно и проверяет именно вашу логику ветвлений, обработку ошибок, выбор сценариев. Мокать сам *gorm.DB бессмысленно и вредно: gorm.DB — конкретная структура, а не интерфейс, честной подмены не получится; самодельные обёртки над каждым методом GORM — это театр, в котором вы проверяете свои же заглушки, а не код. И главное: в слое данных мокам нечего проверять — контракты там охраняет база. Уникальное ограничение, NULL в указателе Deadline, порядок сортировки, счётчик затронутых строк, откат транзакции — всё это существует только в настоящей СУБД. Поэтому репозиторий тестируем на реальной базе, и SQLite in-memory — золотая середина: полноценный SQL-движок в памяти процесса, миллисекунды на старте, никаких серверов и портов. Но надо знать предел этой честности: SQLite — не Postgres. Диалектные отличия прошлого урока — типы колонок, RETURNING, диалект-операторы в строках условий — в in-memory-полигоне не воспроизводятся, и тест, зелёный на SQLite, не докажет, что на Postgres тот же запрос жив. Поэтому зрелая схема трёхслойная: десятки быстрых тестов на in-memory для логики, тесты потребителей на моках интерфейса, и небольшое число интеграционных прогонов на настоящем Postgres в CI — там, где диалект имеет значение. Это мнение стоило бы объявить правилом: мокайте то, что медленное и внешнее по смыслу, и не мокайте то, что и есть предмет проверки. А весь арсенал этого урока — база на тест, транзакционные пузыри и фабрики — соберётся в единый слой данных блога в итоговом проекте двадцать пятого урока: там каждой детали найдётся боевое место.