Интеграционное тестирование с реальной базой

Где гнётся пирамида: что ловит только настоящая база

Спроси себя: что на самом деле тестирует твой сьют с 94% покрытием на моках? Он тестирует, что твой код согласован с твоими допущениями о базе — не то, что база ведёт себя именно так. Вот конкретный класс багов, который живёт в этом зазоре.

Юнит-тесты (замоканные зависимости, ~1мс каждый, их много) проверяют твою логику в изоляции. Интеграционные проверяют, что твой код плюс настоящий коллаборатор — база — действительно работают вместе. В этом различии вся суть: мок возвращает то, что ты в него запрограммировал, поэтому он способен подтвердить лишь те допущения, которые ты уже держишь в голове. А баги, доходящие до прода из слоя данных, — ровно те, что твои допущения упустили:

• Нарушения ограничений — UNIQUE, NOT NULL, CHECK, внешние ключи. Замоканный repo будет «сохранять» дубликат email сколько угодно; Postgres поднимет 23505.
• Правила каскадов — ON DELETE CASCADE / SET NULL переформовывают строки, которых ты явно не касался. Ни один мок не моделирует ссылочное действие.
• Дрифт миграций — миграция, которая не прогналась, колонка, всё ещё varchar(50), отсутствующий индекс. У мока нет схемы, с которой можно дрифтовать.
• Реальный маппинг ORM — колонки JSONB, enum-типы, точность numeric, последовательности, snake_case ↔ camelCase. Настоящая генерация SQL у ORM, а не твоя мысленная модель её.
• Поведение транзакций и изоляции — что rollback действительно откатывает, что блокировка действительно блокирует.

Цена реальна: интеграционным тестам нужен настоящий Postgres, и они бегут за ~10–100мс+ (реальный IO) вместо ~1мс, а старт контейнера стоит ~1–3с один раз на сьют. Поэтому их пишут сильно меньше, чем юнитов, — пирамида остаётся пирамидой. Ты не заменяешь юнит-тесты; ты добавляешь тонкий высокоценный слой, утверждающий то, чего моки не могут.

Почему не замоканный repo и почему не SQLite

Два соблазнительных срезанных угла проваливаются одинаково — дают зелёные тесты, которые врут:

// Мок утверждает ТВОЁ ДОПУЩЕНИЕ, а не реальность.
const repo = { save: jest.fn().mockResolvedValue({ id: 1, email: 'a@b.com' }) };
// Это "проходит", даже если email a@b.com уже есть в проде и дал бы 23505.
// Мок не может обеспечить UNIQUE, не может каскадить, не может прогнать миграцию.

Замоканный repository не поймает нарушение уникальности, не запустит FK-каскад, не вскроет N+1 и не заметит миграцию, которая не прогналась, — потому что он и есть твоё допущение, закодированное. SQLite-как-фейк — ловушка тоньше: это настоящая база, поэтому она кажется честной, но это другой движок, не тот, что в проде. Его аффинность типов, обработка JSONB, семантика последовательностей и поведение изоляции — всё расходится с Postgres. Ты получаешь тесты, зелёные на SQLite и красные в проде, — худший возможный исход, ведь ты им доверял. Сеньорская позиция однозначна: интеграционные тесты бегут на том же движке и мажорной версии, что и прод. Если прод — Postgres 16, контейнер теста — Postgres 16.

Testcontainers: одноразовый Postgres на прогон тестов

@testcontainers/postgresql (библиотека, которая поднимает Docker-контейнеры из кода теста и сносит их после) поднимает настоящий одноразовый Postgres в Docker на время прогона и отдаёт тебе динамический URL подключения. Ты скармливаешь этот URL в TypeOrmModule.forRoot в тестовом модуле, прогоняешь против него настоящие миграции (никогда synchronize: true — это пропускает те самые миграции, которые ты должен протестировать), выполняешь сьют и сносишь контейнер. Один beforeAll собирает всё:

import { Test } from '@nestjs/testing';
import { TypeOrmModule, getDataSourceToken } from '@nestjs/typeorm';
import { DataSource } from 'typeorm';
import { PostgreSqlContainer, StartedPostgreSqlContainer } from '@testcontainers/postgresql';
import { UsersModule } from '../src/users/users.module';

let container: StartedPostgreSqlContainer;
let dataSource: DataSource;

beforeAll(async () => {
  // ~1–3с один раз: настоящий Postgres ТОЙ ЖЕ мажорной версии, что и прод
  container = await new PostgreSqlContainer('postgres:16').start();

  const moduleRef = await Test.createTestingModule({
    imports: [
      TypeOrmModule.forRoot({
        type: 'postgres',
        url: container.getConnectionUri(), // динамические host/port — никогда не хардкодь 5432
        entities: [/* … */],
        synchronize: false,                // тестируем НАСТОЯЩИЕ миграции, не авто-синк
        migrationsRun: false,              // мы прогоняем их явно ниже
      }),
      UsersModule,
    ],
  }).compile();

  dataSource = moduleRef.get<DataSource>(getDataSourceToken());
  await dataSource.runMigrations();        // прогоняем тот же SQL, что прогонит прод
}, 60_000);                                // щедрый таймаут: тянуть образ медленно на холодном кэше

afterAll(async () => {
  await dataSource?.destroy();
  await container?.stop();                  // утилизируем одноразовую БД
});

Вызов runMigrations() вместо synchronize: true — несущая деталь: значит, миграция, которая дропает колонку, добавляет ограничение или бэкфилит данные, реально выполняется в тесте, поэтому дрифт миграций всплывает здесь, а не в проде.

Пер-тестовая изоляция: техника, решающая, можно ли доверять сьюту

Тесты не должны видеть данные друг друга. Флакость из Hook пришла из общего изменяемого состояния — один тест вставил строку, другой посчитал строки и получил число, зависящее от порядка тестов. Три стратегии в порядке предпочтения:

// (a) ПРЕДПОЧТИТЕЛЬНО — оборачиваем каждый тест в транзакцию и ROLLBACK после.
//     Быстрее всего: ничего не коммитится, значит и чистить нечего.
let qr;
beforeEach(async () => {
  qr = dataSource.createQueryRunner();
  await qr.connect();
  await qr.startTransaction();             // BEGIN
  // отдаём qr.manager тестируемому коду, чтобы его записи жили в ЭТОЙ tx
});
afterEach(async () => {
  await qr.rollbackTransaction();          // ROLLBACK — каждая запись исчезает
  await qr.release();
});

// (b) НАДЁЖНО — TRUNCATE всех таблиц между тестами. Переживает код, который
//     коммитит свои транзакции, но медленнее (реальные DELETE + перетряска индексов).
afterEach(async () => {
  const tables = dataSource.entityMetadatas.map((m) => `"${m.tableName}"`).join(', ');
  await dataSource.query(`TRUNCATE ${tables} RESTART IDENTITY CASCADE;`);
});

// (c) ПАРАЛЛЕЛЬНО — свежая схема (или база) на каждый ФАЙЛ тестов, чтобы воркеры
//     не делили состояние. Максимум изоляции, максимум настройки; для параллелизма.

Стратегия (a) быстрее всего, потому что откатанная транзакция ничего не коммитит — чистить нечего. Но у неё острый край: она ломается в момент, когда тестируемый код управляет своей транзакцией и коммитит. Если твой сервис открывает свой dataSource.transaction(...) и коммитит внутри, этот коммит сбегает из твоей внешней тестовой транзакции (или вложенный savepoint освобождается), и твой ROLLBACK его больше не отменяет. Для такого кода откатывайся к (b) TRUNCATE. Ловушка, которую надо усвоить: общее изменяемое состояние БД + параллельный раннер = зависящая от порядка флакость. Изолируй на каждый тест или на каждого воркера — никогда не давай двум тестам трогать одни закоммиченные строки.