Тестируем pgx на живой базе

Каркас любого pgx-теста собирается из четырёх шагов, и все они уже знакомы по уроку про модуль Postgres: postgres.Run поднимает контейнер и возвращает postgres.PostgresContainer, ConnectionString собирает DSN с реальным хостом и портом — их знает только Docker, — pgxpool.New открывает пул по этому DSN, pool.Ping подтверждает, что база отвечает. Импорт выглядит как `github.com/testcontainers/testcontainers-go/modules/postgres`, а пул берётся из пакета `pgxpool` библиотеки pgx: одна строка DSN — и нативный клиент работает без database/sql. Уборка живёт в t.Cleanup: пул закрывается первым, Terminate останавливает контейнер вторым — если погасить базу раньше, закрытие пула встретит мёртвые соединения и добавит в лог шум. Каркас оформляется хелпером с t.Helper: setupTestDB принимает testing.T и возвращает *pgxpool.Pool, и каждый тест пакета получает свежую базу одной строкой. Пул на тест — не расточительство: соединения живут в пределах Cleanup, и гонки за свободные коннекты между тестами не возникают; экономить пулы имеет смысл позже, когда появится reuse. Адрес контейнера меняется от запуска к запуску: порт выбирает Docker из свободных, поэтому DSN собирается вызовом ConnectionString, а не константой в конфиге.

Схему в тестовую базу можно доставить двумя способами. Первый — pool.Exec с простым CREATE TABLE прямо из хелпера: минимальная миграция на три строки, вся схема видна в самом тесте, ничего не прячется в файлах. Второй — WithInitScripts из модуля: он монтирует ваши SQL-файлы в /docker-entrypoint-initdb.d/, и официальный образ Postgres исполняет их при старте контейнера в порядке сортировки имён — если порядок критичен, у модуля есть WithOrderedInitScripts, который нумерует файлы сам. Практическое правило: если схему ведёт отдельный инструмент миграций и файлы уже лежат в репозитории — WithInitScripts прогонит именно их, и тест увидит ту же схему, что прод; файлы при этом исполняются образом до того, как пул подключится, — к первому Ping схема уже готова. Если тесту нужны две таблицы и индекс — Exec дешевле и прозрачнее: никакой синхронизации файлов, вся схема перед глазами, а вариация схемы под конкретный тест — правка одной строки, а не файла. Смешивать оба пути в одном пакете не нужно: потом никто не вспомнит, кто владеет какой таблицей.

Полный CRUD-тест делает три вещи, которые мок не проверит никогда. INSERT с RETURNING id возвращает сгенерированный ключ — заглушка подставила бы единицу, база честно считает BIGSERIAL и отдаёт следующее значение. SELECT со Scan раскладывает колонки по переменным: несовпадение типов вскроется здесь, потому что Scan конвертирует настоящий вывод движка, а не структуру, которую вы же и заготовили. UPDATE сверяется через RowsAffected: ноль затронутых строк значит, что промахнулись по id, и тест обязан это видеть. Отдельный козырь живой базы — ошибки ограничений: второй INSERT с тем же email падает, и pgx возвращает *pgconn.PgError с полем Code. Проверка через errors.As — каноничный способ из курса pgx: код 23505 означает unique_violation, 23503 — foreign_key_violation, 23502 — not_null_violation. Таблицы SQLSTATE живут в документации Postgres, и они стабильнее любых сообщений: текст ошибки меняется между версиями, код — нет. Тот же тест с моком вернул бы nil на обоих INSERT — потому что и индекс, и дубликат существовали только в вашей голове. NULL-колонки сюда же: в поле без указателя Scan вернёт ошибку конвертации, и увидите вы её только на настоящем выводе движка.

Как только pgx-тестов становится больше одного, вопрос изоляции данных решает, останутся ли тесты базы данных go воспроизводимыми: каждый прогон должен видеть базу в одном и том же состоянии, иначе тесты начнут падать по очереди — в зависимости от того, кто шёл первым. Это главный компромисс направления: скорость против независимости. Свежая база на тест — новый контейнер из postgres.Run: полная изоляция, но секунды на каждый тест. Отдельная схема на тест — CREATE SCHEMA test_xxx и SET search_path в строке подключения: один контейнер, у каждого теста своё пространство имён, дёшево и почти так же чисто. Транзакция с откатом — тест работает внутри Begin, а Cleanup вызывает Rollback: мгновенно, но только пока тест не делает DDL или собственный COMMIT. TRUNCATE между тестами — чистые таблицы одним вызовом, но легко забыть таблицу и получить данные соседа. У модуля есть и пятый путь: Snapshot после миграций и Restore перед тестом — база копируется из шаблона, механика спрятана в модуле. Стратегия выбирается на весь пакет, а не на отдельный тест: половина тестов на транзакциях, половина на TRUNCATE — гарантий нет ни у кого. Таблица ниже сводит варианты по скорости и надёжности.

Мок — это зеркало ваших ожиданий, и четыре класса багов он не отражает в принципе. Типы: pgx сканирует timestamptz, NUMERIC, UUID, массивы — несовпадение обнаружится только при живом Scan, потому что конвертацию выполняет драйвер против настоящего вывода движка. Планировщик: запрос, который на заглушке «возвращает список», на живой таблице может читать её целиком — seq scan увидит только Postgres, а тест с EXPLAIN увидит его вместе с базой. Ограничения: NOT NULL, CHECK, внешние ключи и уникальные индексы существуют только в схеме — мок о них не знает, а база расскажет кодом ошибки. Каскады: ON DELETE CASCADE и триггеры сработают лишь в реальном движке, и тест, удаляющий родителя, проверит, что дети уехали сами. Добавим пятый класс — парсинг SQL: мок принимает любую строку, а база разбирает её синтаксисом; опечатка в имени колонки на заглушке зелёная, на живой базе — честная ошибка undefined column. Юнит-слой с заглушками оставьте для бизнес-правил: там он быстр и уместен. Но граница — ровно интерфейс хранилища: за ним начинается база, и тестировать её нужно настоящей.