Моки, тест-дублёры и ловушка чрезмерного мокинга

Словарь тест-дублёров, употреблённый точно

Почему важна точность словаря? Потому что когда ты называешь что-то «моком» и тянешься за jest.fn(), ты уже решил, что тест проверяет — а это решение может оказаться неверным так, что выяснится только в продакшене. Точный выбор слова заставляет точно выбрать поведение.

«Мок» — слово, которым все называют всё подряд, и эта небрежность прячет, что тест на самом деле проверяет. Видов пять, и разница между ними — это разница между проверкой состояния (assert на результат) и проверкой поведения (assert, что вызов случился).

• Dummy передаётся, чтобы удовлетворить сигнатуру, но никогда не используется — аргумент-заполнитель.
• Стаб возвращает заготовленные ответы. Ты используешь его для проверки состояния: запрограммируй его вернуть пользователя, затем проверь, что твой код вычислил из этого пользователя. Ему всё равно, вызвали ли его.
• Спай записывает, как его вызвали (и может опционально пробросить вызов в настоящую реализацию). Ты проверяешь, что его вызвали, с какими аргументами, сколько раз.
• Мок имеет заранее запрограммированные ожидания и проваливает тест, если они не выполнены. Это проверка поведения: assert запечён в самом дублёре.
• Фейк — рабочая лёгкая реализация: in-memory репозиторий на Map, фейковые часы. Он действительно ведёт себя как настоящий, просто без IO.

// stub: canned return, used for STATE verification (assert on the computed result)
const repoStub = { findOne: jest.fn().mockResolvedValue({ id: 1, email: 'a@b.com' }) };

// spy: assert it WAS called, with what (behaviour, but read-only)
const mailSpy = jest.fn();
expect(mailSpy).toHaveBeenCalledWith('a@b.com');

// fake: a real, working in-memory impl — it enforces its own contract
class FakeUserRepo {
  private rows = new Map<number, User>();
  async findOne({ where: { id } }: any) { return this.rows.get(id) ?? null; } // returns null!
  async save(u: User) { this.rows.set(u.id, u); return u; }
}

Обрати внимание: findOne фейка возвращает null на отсутствующий id — потому что так делает настоящий. Стаб, который всегда возвращает пользователя, никогда не сможет породить эту ветку. Точный выбор слова заставляет тебя точно выбрать поведение. Вместе пять типов покрывают все потребности: стаб и фейк — для проверки состояния, спай и мок — для проверки поведения, dummy — для заглушки сигнатуры. Пропустишь фейк — потеряешь единственного дублёра, который на самом деле обеспечивает реальный контракт.

Подмена провайдеров в Nest: override, а не jest.mock

Тестовый модуль ты уже собираешь через Test.createTestingModule. Специфичный для мокинга манёвр — подмена реального провайдера дублёром через DI Nest, вызовом overrideProvider(...).useValue(...) до .compile(). Это важно, потому что подмена идёт через контейнер — SUT получает дублёр по тому же токену, по которому получил бы настоящую зависимость, и больше ничто в графе этого не замечает.

const mailMock = { send: jest.fn() };
const repoMock = { findOne: jest.fn(), save: jest.fn() };

const moduleRef = await Test.createTestingModule({
  providers: [UsersService, MailService /* real token, will be overridden */],
})
  .overrideProvider(MailService).useValue(mailMock)
  // a TypeORM repo is injected by a TOKEN, not the class — override the token
  .overrideProvider(getRepositoryToken(User)).useValue(repoMock)
  .compile();

const service = moduleRef.get(UsersService);

Строка с репозиторием — та, где ошибаются: @InjectRepository(User) инжектит под getRepositoryToken(User), строко-подобным токеном, а не классом Repository. Подменяй токен, а не Repository. И сопротивляйся jest.mock('@nestjs/typeorm') для этого — мокинг на уровне модуля воюет с DI Nest: он заменяет символ глобально до того, как контейнер что-либо свяжет, так что ты теряешь контроль на уровне теста и токена и в итоге дебажишь, почему несвязанный тест в том же файле теперь видит твой мок. overrideProvider ограничен этим тестовым модулем и говорит на языке DI.

Auto-mocking: перестань писать пустые объекты руками

Писать руками { findOne: jest.fn(), save: jest.fn(), find: jest.fn(), ... } для широкой зависимости утомительно и протухает. useMocker в Nest вешает фабрику на любую непредоставленную зависимость; в паре с createMock из @golevelup/ts-jest он авто-генерирует глубокий, полностью типизированный мок всего интерфейса, и ты программируешь только те методы, которых касается тест.

import { createMock } from '@golevelup/ts-jest';

const moduleRef = await Test.createTestingModule({ providers: [UsersService] })
  .useMocker(createMock) // every missing dep becomes a deep auto-mock typed to its interface
  .compile();

const repo = moduleRef.get(getRepositoryToken(User));
repo.findOne.mockResolvedValue({ id: 1, email: 'a@b.com' }); // program just what you need

У удобства острый край: глубокий авто-мок типизирован к интерфейсу, так что он с радостью выдаст jest.fn() для метода, которого уже нет на реальном типе, или для метода, у которого уехала сигнатура. Мок удовлетворяет компилятор против формы, которую реальность с тех пор покинула — а это ровно тот провал, о котором следующий раздел.

Ловушка чрезмерного мокинга

Мок кодирует твоё предположение о том, как ведёт себя зависимость. Это нормально для границы, которой ты не владеешь — платёжный шлюз, почтовый провайдер, сторонний HTTP API — где ты не можешь гонять настоящую вещь в юнит-тесте, а контракт стабилен и внешний. Это ловушка для того, чем ты владеешь.

Канонический провал — тот, что из Hook. Мок репозитория всегда возвращает { id, email }; реальный запрос на not-found возвращает null. Сервис делает user.email. Тест зелёный; прод выбрасывает Cannot read properties of null. Брат-близнец: замоканный save никогда не обеспечивает реальное ограничение UNIQUE(email), так что тест «отклонить дубликат email» проходит против мока, который радостно сохраняет дважды — тест не может поймать дубликат, потому что у мока нет ограничения, которое можно нарушить. В обоих случаях тест тестирует мок, а не код. Перемокай — и твой зелёный сьют измеряет точность твоих предположений, а не корректность твоей системы.

Позиция сеньора — это граница, проведённая осознанно:

• Мокай на архитектурных границах, которыми не владеешь — сторонний HTTP, почта, платежи, очереди. Их нельзя гонять в юнит-тесте; их контракт внешний и редко меняется под тобой.
• Фейкай или интегрируй то, чем владеешь — твой репозиторий, твои доменные сервисы. Используй in-memory фейк, который чтит контракт (возвращает null на промахе, обеспечивает уникальность), или интеграционный тест на настоящей БД. Это части, которые вероятнее всего дрейфуют, поэтому именно их мок опаснее всего замораживает.
• Держи моки честными интеграционными тестами, которые прогоняют реальный контракт. Юнит-тесты с моками идут в однозначных миллисекундах, потому что нет IO — эта скорость и есть вся причина мокать. Цена — точность. Ты покупаешь скорость там, где точность дешева (стабильные границы), и платишь за точность там, где она важна (твой собственный слой данных), с более тонким слоем интеграционных тестов, прикалывающих реальный контракт, чтобы дрейф делал тест красным, а не пейджер.