E2E-тестирование через supertest

Подними всё приложение, потом говори с ним по HTTP

За десять минут у тебя будет рабочая e2e-настройка, которая ловит баги обвязки, невидимые unit-тесту: pipe, отклоняющий поле, guard, молча блокирующий маршрут.

Unit-тест инстанцирует один класс с фейками вокруг. E2E-тест делает наоборот: он компилирует весь граф модулей из AppModule, строит настоящее приложение Nest и гоняет его через HTTP-листенер. Два метода, которые ты пропускаешь в unit-тестах, здесь становятся центральными. compile() строит только граф провайдеров — у HttpAdapterHost ещё нет сервера. createNestApplication() — это то, что инстанцирует полный рантайм с HTTP-адаптером; app.init() затем выполняет все lifecycle-хуки (onModuleInit, onApplicationBootstrap) и регистрирует твои глобальные pipes, guards, interceptors и filters.

import * as request from 'supertest';
import { Test, TestingModule } from '@nestjs/testing';
import { INestApplication, ValidationPipe } from '@nestjs/common';
import { AppModule } from '../src/app.module';

describe('Users (e2e)', () => {
  let app: INestApplication;

  beforeAll(async () => {
    const moduleRef: TestingModule = await Test.createTestingModule({
      imports: [AppModule],          // ВСЁ приложение, не один провайдер
    }).compile();

    app = moduleRef.createNestApplication();
    app.useGlobalPipes(new ValidationPipe({ whitelist: true })); // зеркалим main.ts
    await app.init();                // запускает lifecycle-хуки + обвязывает глобалы
  });

  it('POST /users then GET /users/:id', async () => {
    const created = await request(app.getHttpServer())
      .post('/users')
      .send({ email: 'ada@example.com', name: 'Ada' })
      .expect(201);

    await request(app.getHttpServer())
      .get(`/users/${created.body.id}`)
      .expect(200)
      .expect((res) => {
        if (res.body.email !== 'ada@example.com') throw new Error('email mismatch');
      });
  });

  afterAll(async () => {
    await app.close();               // освобождает хендлы БД + открытые сокеты
  });
});

request(app.getHttpServer()) передаёт supertest (HTTP-клиент для Node.js, умеющий биндить приложение без реального порта) нижележащий Node HTTP-листенер. Supertest биндит его на эфемерный порт, шлёт настоящий запрос, и ответ проходит по настоящему pipeline. Этот единственный .post('/users') прогоняет твой глобальный ValidationPipe, каждый guard на маршруте, контроллер, сервис, repository против реальной БД и твой exception filter на выходе — именно поэтому такой тест ловит баги обвязки, которые unit-тест замокал.

Направь приложение на реальную одноразовую тестовую БД

БД — это то, что делает e2e честным. Замокай repository — и ты соврал про тот самый слой, который ломается чаще всего: ограничения, транзакции, реальный SQL. Поэтому честный e2e-набор гоняется против реальной, но эфемерной БД: dockerized Postgres (часто через Testcontainers, который поднимает одноразовый контейнер на прогон) или лёгкого движка вроде sqlite. Ты прогоняешь миграции, чтобы построить схему, засеваешь фикстуры и — критически — сбрасываешь состояние между тестами, чтобы они оставались независимыми.

Ты переопределяешь продовый data source, чтобы приложение говорило с тестовой БД. С TypeORM подмени провайдер DataSource по его токену:

import { getDataSourceToken } from '@nestjs/typeorm';
import { DataSource } from 'typeorm';

const testDataSource = new DataSource({
  type: 'postgres',
  url: process.env.TEST_DATABASE_URL,  // одноразовый контейнер, не прод
  entities: [User],
  synchronize: false,                  // вместо этого гоняем реальные миграции
});

beforeAll(async () => {
  await testDataSource.initialize();
  await testDataSource.runMigrations();

  const moduleRef = await Test.createTestingModule({ imports: [AppModule] })
    .overrideProvider(getDataSourceToken())   // заменяем продовый DataSource...
    .useValue(testDataSource)                 // ...на тестовый
    .compile();

  app = moduleRef.createNestApplication();
  await app.init();
});

beforeEach(async () => {
  // изоляция: вытираем строки между тестами, чтобы порядок никогда не имел значения
  await testDataSource.query('TRUNCATE TABLE "user" RESTART IDENTITY CASCADE');
});

TRUNCATE между тестами — самый дешёвый путь к изоляции: каждый it стартует с заведомо пустой таблицы, так что тест, создающий пользователя, не может отравить следующий. Альтернатива — оборачивать каждый тест в транзакцию и откатывать — быстрее, но ломается, когда твой код открывает собственные транзакции. Конфиг через переменные окружения (.env.test, направляющий DATABASE_URL на контейнер) — более простая альтернатива overrideProvider, когда всё приложение читает одну строку подключения.

Auth в тестах: реальный токен или обход guard

Если твои маршруты сидят за JwtAuthGuard, каждый e2e-запрос должен его удовлетворить — и у тебя два честных варианта. Вариант один: получи реальный токен. Сходи на /auth/login (или подпиши токен тестовым секретом) и приложи его, чтобы guard выполнился по-настоящему:

let token: string;
beforeAll(async () => {
  const res = await request(app.getHttpServer())
    .post('/auth/login')
    .send({ email: 'ada@example.com', password: 'pw' });
  token = res.body.accessToken;
});

it('GET /me with a real JWT', () =>
  request(app.getHttpServer())
    .get('/me')
    .set('Authorization', `Bearer ${token}`)   // guard выполняется, валидирует токен
    .expect(200));

Вариант два: переопредели guard, когда auth — не то, что ты тестируешь, чтобы не платить за танец с логином в каждой спеке:

const moduleRef = await Test.createTestingModule({ imports: [AppModule] })
  .overrideGuard(JwtAuthGuard)
  .useValue({ canActivate: () => true })   // каждый запрос «аутентифицирован»
  .compile();

Компромисс — реалистичность против скорости. Реальный токен прогоняет весь путь auth — подпись токена, guard, strategy, заполнение req.user — так что ловит баги обвязки auth; он медленнее и связывает твой тест с flow логина. Переопределение guard быстрое и сфокусированное, но это значит, что данный набор не доказывает ничего про аутентификацию, так что тебе всё равно нужна хотя бы одна спека, использующая реальный токен от начала до конца.

Гигиена lifecycle: закрой приложение, изолируй состояние

Самый частый провал e2e — не ассерт, а Jest, зависший в конце с «a worker process has failed to exit gracefully… open handles». Это приложение, которое ты поднял, но не закрыл: пул БД и HTTP-сокет всё ещё открыты. afterAll(() => app.close()) выполняет shutdown-хуки и освобождает их. Сочетай это со сбросом состояния БД на каждый тест и никогда не давай одному тесту зависеть от объедков другого.