Unit-тестирование провайдеров через testing module

Testing module — это одноразовый DI-контейнер

Когда видишь девятиминутный «unit»-сьют, спроси себя: зачем ему база данных? Почти всегда — незачем. Testing module возвращает это время обратно.

Test.createTestingModule({ providers: [...] }) собирает свежий, изолированный DI-контейнер Nest, в котором есть только то, что ты перечислил. Вызов .compile() резолвит граф и отдаёт TestingModule; module.get(Token) достаёт из него singleton-экземпляр — твой юнит под тестом, уже связанный. Поскольку массивом providers управляешь ты, ты решаешь, какие зависимости реальные, а какие — дублёры. Сервис под тестом перечисляй реальным классом, а каждую зависимость, которую он инжектит, подставляй как мок.

Самый чистый способ подставить мок — кастомный провайдер с useValue: тот же injection-токен, фейковая реализация. jest.fn() на каждый метод даёт шпиона, которого можно запрограммировать и по которому можно проверять.

import { Test, TestingModule } from '@nestjs/testing';
import { getRepositoryToken } from '@nestjs/typeorm';
import { Repository } from 'typeorm';
import { UsersService } from './users.service';
import { User } from './user.entity';

describe('UsersService', () => {
  let service: UsersService;
  let repo: jest.Mocked<Repository<User>>;

  beforeEach(async () => {
    const module: TestingModule = await Test.createTestingModule({
      providers: [
        UsersService, // реальный — это юнит под тестом
        {
          provide: getRepositoryToken(User), // токен, который Nest инжектит для @InjectRepository(User)
          useValue: {
            findOne: jest.fn(),
            create: jest.fn((dto) => dto),
            save: jest.fn(),
          },
        },
      ],
    }).compile();

    service = module.get(UsersService);
    repo = module.get(getRepositoryToken(User));
  });

  it('отклоняет дублирующий email без сохранения', async () => {
    repo.findOne.mockResolvedValue({ id: 1, email: 'a@b.io' } as User);

    await expect(service.register({ email: 'a@b.io', password: 'pw' }))
      .rejects.toThrow('email already in use');

    expect(repo.save).not.toHaveBeenCalled(); // поведение, а не деталь реализации
  });

  it('сохраняет нового пользователя ровно один раз', async () => {
    repo.findOne.mockResolvedValue(null);
    repo.save.mockResolvedValue({ id: 7, email: 'new@b.io' } as User);

    const result = await service.register({ email: 'new@b.io', password: 'pw' });

    expect(repo.save).toHaveBeenCalledTimes(1);
    expect(repo.save).toHaveBeenCalledWith(
      expect.objectContaining({ email: 'new@b.io' }),
    );
    expect(result.id).toBe(7);
  });
});

Две детали оправдывают себя. Токен для TypeORM-repository — это не класс сущности, а getRepositoryToken(User), синтетический токен, в который резолвится @InjectRepository(User). Подставь значение под этот токен — и сервис получит твой мок. И проверки сделаны по поведению: «не сохранил при дубле», «сохранил один раз с этим email». Они никогда не лезут в приватные поля сервиса. Тесты, завязанные на поведение, переживают рефакторинг; тесты, завязанные на реализацию, ломаются в тот момент, когда ты переименовал переменную.

Мокай на границе — и только там

Тот же паттерн покрывает любого внешнего коллаборатора. JwtService, HTTP-клиент, оборачивающий платёжный API, mailer — каждый это шов между твоей логикой и внешним миром, и каждый получает useValue-дублёра по своему токену. Что ты не мокаешь — это сам юнит под тестом (тогда ты не тестируешь ничего) и чистые внутренние хелперы вроде value object или функции оценки сложности пароля — мок таких лишь замораживает реализацию и тестирует твой мок вместо твоего кода. Мокай I/O-границу; дай логике выполниться.

Для сервиса, который общается и с repository, и с внешним клиентом, это два дублёра:

const module = await Test.createTestingModule({
  providers: [
    OrdersService,
    { provide: getRepositoryToken(Order), useValue: { findOne: jest.fn(), save: jest.fn() } },
    { provide: PaymentClient, useValue: { charge: jest.fn().mockResolvedValue({ ok: true }) } },
  ],
}).compile();

Теперь OrdersService.checkout можно прогнать по каждой ветке — отказ платежа, конфликт в repository, счастливый путь — за миллисекунды, детерминированно, без сети и без БД.

overrideProvider, когда модуль реальный

useValue работает, когда провайдеры собираешь ты сам. Иногда удобнее импортировать реальный feature-модуль — чтобы его связка оставалась честной — и подменить только листовые зависимости. Это overrideProvider(TOKEN):

const module = await Test.createTestingModule({
  imports: [UsersModule], // реальный модуль, реальная связка
})
  .overrideProvider(getRepositoryToken(User))
  .useValue({ findOne: jest.fn(), save: jest.fn() })
  .compile();

После .useValue(...) можно вместо этого зацепить .useClass(FakeRepo) (класс-заглушку, которую Nest инстанцирует со своими зависимостями) или .useFactory({ factory: () => mock }) (когда дублёру нужна логика конструирования). А если не хочешь называть каждого дублёра, .useMocker((token) => ...) авто-заглушит всё, что не подставлено явно, — удобно для сервиса с длинным списком зависимостей, где тебе важны один-два коллаборатора, а остальные пусть будут инертными no-op-моками.

Два способа подставить зависимость, бок о бок