Тест-дублёры и моки: швы, а не кувалда

Пять дублёров, названных точно

Когда коллега говорит «просто замокай это» — какой из пяти инструментов он имеет в виду? От ответа зависит, ловит ли твой тест баги или просто отражает твои допущения обратно.

«Мок» — слово, к которому тянется каждый, и чаще всего ошибочно. По таксономии Мезароша (её популяризировал Фаулер) есть пять видов тест-дублёров, различаемых по тому, что они делают и на что ты проверяешь. Dummy — заглушка, которую ты передаёшь, чтобы удовлетворить сигнатуру, и никогда не используешь: null, {}, пустая функция. Stub возвращает заготовленные значения, чтобы провести путь: getUser() всегда отдаёт одного и того же админа, и ты тестируешь ветку админа. Spy — это stub, который вдобавок записывает, как его вызвали, чтобы потом проверить аргументы и число вызовов. Mock заранее запрограммирован ожиданиями: он знает, какие вызовы должен получить, и сам валит тест, если реальность расходится. Fake — настоящая, рабочая, лёгкая реализация: in-memory репозиторий на Map вместо Postgres, полностью функциональный, но непригодный для прода.

Граница, важная на senior-уровне, — верификация состояния vs верификация поведения. Stub и fake позволяют проверять итог — в каком состоянии оказалась система. Spy и mock тянут тебя проверять взаимодействие — какие методы вызвались и в каком порядке. Проверки взаимодействия соблазнительны и хрупки: они привязывают тест к текущей реализации, так что рефакторинг с тем же поведением может сделать сьют красным. Баг из хука — обратный провал: проверялось только взаимодействие, поэтому сломанный итог остался зелёным.

В node:test (встроен с Node 18, стабилен в 20) дублёр — это mock.fn(), а метод патчишь через mock.method(obj, 'name') — оба авто-восстанавливаются в конце теста, если использовать трекер моков контекста. Vitest повторяет это через vi.fn() и vi.spyOn(obj, 'method'). Вот spy поверх реального объекта, проверяющий и итог, и взаимодействие:

import { test } from "node:test";
import assert from "node:assert/strict";

test("notify spies on the mailer", () => {
  const mailer = { send: () => "queued" };
  const spy = test.mock.method(mailer, "send");   // wraps the real method

  notify(mailer, "you@co.com", "hi");

  // interaction: was it called, and how?
  assert.equal(spy.mock.calls.length, 1);
  assert.deepEqual(spy.mock.calls[0].arguments, ["you@co.com", "hi"]);
});

Швы: подменить поведение, не трогая тестируемый код

Шов (seam) — это место, где можно изменить поведение, не правя тестируемый код (термин Физерса) — и самый полезный взгляд на тестируемость. Каждому дублёру нужен шов, чтобы в нём жить, и по сути швов у тебя два.

Чистый шов — внедрение зависимостей (DI): коллаборатор приходит как аргумент (конструктор, параметр функции, фабрика), так что тест просто передаёт stub или fake вместо настоящего. Никакой магии, никакого фреймворка, безопасно к рефакторингу — обвязка это обычные значения, текущие через обычные API. Цена в том, что это видно в сигнатуре: charge(order) становится charge(order, { gateway, clock }), что часть команд отвергает как «урон, наведённый тестами».

Другой шов — мокирование модуля, когда внедрить нельзя: модуль делает import { readFile } from "node:fs/promises" и вызывает напрямую. node:test даёт mock.module(specifier, { namedExports }); Vitest — vi.mock('./mod'). Подвох Vitest — хойстинг: vi.mock поднимается в начало файла выше твоих импортов, так что его фабрика не должна ссылаться на внешние переменные (используй vi.hoisted(), если нужно), а мок применяется ко всем импортёрам этого модуля на весь тестовый файл.

// Vitest module mock — поднимается выше импортов, применяется ко всему файлу
import { vi, test, expect } from "vitest";
import { loadConfig } from "./config.js";

vi.mock("node:fs/promises", () => ({
  readFile: vi.fn().mockResolvedValue('{"port":8080}'),
}));

test("parses config from disk", async () => {
  expect(await loadConfig("/app.json")).toEqual({ port: 8080 });
});

Фейковые таймеры: сжать реальные секунды в микросекунды

Код, который ждёт, — ретрай с бэкоффом, дебаунс, опрос, TTL кеша — не тестируем в реальном времени: 30-секундный экспоненциальный бэкофф (1 с, 2 с, 4 с, 8 с, с потолком 15 с) сделал бы один тест ценой в полминуты. Фейковые таймеры подменяют setTimeout, setInterval и Date.now/Date управляемыми часами, которые ты двигаешь вручную, так что виртуальное время идёт за нулевую реальную цену. node:test включает их на тест через t.mock.timers.enable({ apis: ['setTimeout', 'Date'] }) и двигает через t.mock.timers.tick(ms); Vitest — через vi.useFakeTimers() и vi.advanceTimersByTime(ms) / await vi.advanceTimersByTimeAsync(ms).

Острый подвох — таймеры и микротаски это разные очереди. tick/advanceTimersByTime запускает колбэки таймеров, но промисы, которые эти колбэки резолвят, лежат в очереди микротасков, а она опустошается только когда ты делаешь await. Так что для асинхронного ретрая надо и продвинуть время, и уступить — advanceTimersByTimeAsync у Vitest делает оба; с синхронной версией ты вставляешь await Promise.resolve() или await flushPromises(). Сделай это верно — и бэкофф в 30 с реального времени отработает меньше чем за 5 мс.

import { vi, test, expect } from "vitest";

test("retries with backoff, virtually", async () => {
  vi.useFakeTimers();
  const op = vi.fn()
    .mockRejectedValueOnce(new Error("503"))
    .mockResolvedValueOnce("ok");

  const p = retryWithBackoff(op, { base: 1000 }); // would sleep 1s for real
  await vi.advanceTimersByTimeAsync(1000);        // advance clock AND flush microtasks

  expect(await p).toBe("ok");
  expect(op).toHaveBeenCalledTimes(2);
  vi.useRealTimers();
});

Провальный режим: овермокинг выкатывает зелёные баги

Глубочайший провал этого урока — овермокинг: замокать ровно то, что тестируешь, или столько вокруг, что тест больше не прогоняет реальный код. Когда ты мокаешь коллаборатора, чьё поведение и есть суть, мок кодирует допущение — и если это допущение и есть баг, тест утверждает, что баг корректен. Хук — каноничный случай: stripe.charges.create замокали всегда возвращать успех, так что дефект «доллары вместо центов» никогда не мог сделать сьют красным. Второй, тлеющий медленнее вариант — дрейф контракта: API реальной зависимости меняется (переименовали поле, добавили статус, 200-с-телом-ошибки), а рукописный мок нет, так что тесты остаются зелёными против выдумки, пока прод отдаёт 500.

Числа убийственны. Реальный проверенный сьют имел ~400 проверок вызовов моков и ноль реального I/O — каждая внешняя граница застаблена — и пропустил изменение схемы в теле ответа, сломавшее десериализацию в проде в течение часа после деплоя; моки были заморожены на старой форме месяцами. Фикс — не лозунг «мокай меньше», а три конкретных шага: (1) на критичном шве предпочти fake или реальный интеграционный тест стабу, чтобы прогонять поведение, а не свою догадку о нём; (2) проверяй итог, а не число вызовов — expect(result.chargedCents).toBe(4900), а не expect(stripe.create).toHaveBeenCalled(); (3) контракт-тестируй границу — гоняй маленький сьют против реальной зависимости (или её записанных ответов / контракта провайдера), чтобы изменение формы громко валило этот тест, а не протекало мимо твоего замороженного мока. Вместе эти три шага переключают сьют с зеркала твоих допущений в реальный зонд поведения кода: шаг (1) добавляет настоящую логику в путь теста, шаг (2) делает ассерт наблюдаемым, шаг (3) держит форму мока честной — без всех трёх любой из них по-прежнему пропустит баг в прод.

// ❌ over-mock: asserts the mock was called, not that the charge is right
test("charges the order", async () => {
  const stripe = { charges: { create: vi.fn().mockResolvedValue({ status: "succeeded" }) } };
  await checkout(order, { stripe });
  expect(stripe.charges.create).toHaveBeenCalled();   // green even at $4900
});

// ✅ assert outcome against a behavior-honouring fake
test("charges the order in cents", async () => {
  const fakeGateway = makeFakeGateway();              // validates & records real amounts
  const receipt = await checkout(order, { gateway: fakeGateway });
  expect(receipt.chargedCents).toBe(4900);            // catches dollars-vs-cents
});