Изоляция тестов и флакающие тесты: добиваемся детерминизма

Почему тесты флакают: общее состояние и неуправляемый недетерминизм

Если тест проходит у тебя и падает в CI, ты смотришь не на загадку, а на одну из двух точно названных корневых причин — и зная их, чинишь проблему за минуты, а не за часы git-bisect.

Детерминированный тест выдаёт один и тот же вердикт в каждом прогоне, в любом порядке, на любой машине. Флак — это отсутствие такого свойства, и у него ровно два корня. Первый — общее изменяемое состояние: два теста трогают одно и то же, и один оставляет его грязным. Классические виновники: синглтон уровня модуля (кэш, пул соединений, объект конфига, загруженный один раз на import), общая строка БД, которую оба теста читают и пишут, или глобальные часы, которые все читают. Второй — неуправляемый недетерминизм: Date.now(), Math.random(), свежесгенерированные UUID, таймзона и локаль хоста, и тайминг — спать фиксированное число миллисекунд и надеяться, что работа закончилась.

Общее состояние порождает зависимость от порядка: тест B проходит только потому, что тест A отработал первым и случайно засеял синглтон. Переставь их — или запусти B один — и B падает. Вот почему набор, зелёный при запуске целиком, может стать красным, когда ты запускаешь один файл через .only.

// shared-state leak: a module-level counter both tests mutate
import { test, expect } from "vitest";
import { idCounter } from "../src/ids.js"; // module-level singleton: let n = 0

test("A: first id is 1", () => {
  expect(idCounter.next()).toBe(1); // passes only if it ran first
});
test("B: ids are sequential", () => {
  const a = idCounter.next();        // 2 if A ran, 1 if B ran alone
  expect(idCounter.next()).toBe(a + 1);
});
// Запусти B через --testNamePattern="B" — и "A: first id is 1" тихо сломается
// при следующем прогоне всего набора: сбой переехал.

Раннеры борются с этим изоляцией. Единица изоляции в дефолтном пуле Vitest и в node:test — это файл: каждый файл теста получает свежий воркер (отдельный процесс или поток-воркер), так что состояние уровня модуля рождается чистым на файл. Это изоляция процессов — герметичная, потому что протёкший синглтон в файле X не может дотянуться до файла Y. Но внутри одного файла тесты делят граф модулей и тот же глобальный объект: это изоляция в общем контексте, и именно тут живут протечки. Понимание, на какой границе ты находишься, говорит, достаточно ли beforeEach или протечка пересекает файлы.

Детерминизм: контролируй время, рандом и окружение

Тест делается детерминированным удалением каждого входа, которым тест явно не владеет. Зафиксируй часы фейковыми таймерами (vi.useFakeTimers() / vi.setSystemTime(...)) или, что лучше для продакшен-кода, внедри часы, чтобы юнит под тестом вызывал clock.now(), а тест подавал замороженные — внедрение зависимостей бьёт глобальный патч, потому что у него нет тирдауна, который можно забыть. Сей рандом так же: внедряй генератор id или сидированный PRNG вместо обращения к Math.random() или crypto.randomUUID() внутри бизнес-логики. Заморозь таймзону, запуская CI с TZ=UTC — единственная переменная окружения, убирающая целый класс флаков с датами, потому что арифметика дат, пересекающая границу перехода на летнее время, ведёт себя иначе в America/New_York, чем в UTC. И никогда не спи на стенных часах, ожидая асинхронную работу — жди настоящий промис или прокручивай фейковые таймеры; setTimeout(50), работающий на твоём ноутбуке, проигрывает гонку на нагруженной машине CI.

// flaky: reads the real clock and a real random source
test("token expires in one hour", () => {
  const t = issueToken();
  expect(t.expiresAt).toBe(Date.now() + 3_600_000); // both sides drift
});

// deterministic: freeze time, inject the id
import { vi, test, expect, afterEach } from "vitest";
afterEach(() => vi.useRealTimers());

test("token expires one hour after issue", () => {
  vi.useFakeTimers();
  vi.setSystemTime(new Date("2026-06-05T00:00:00Z"));
  const t = issueToken({ now: () => Date.now(), id: () => "fixed-id" });
  expect(t.expiresAt).toBe(Date.parse("2026-06-05T01:00:00Z")); // exact, always
});

Компромисс лежит между двумя режимами изоляции. Полная изоляция процессов на файл герметична, но медленна: запуск воркера стоит примерно десятки миллисекунд, так что набор из тысячи файлов платит секунды-десятки секунд чистого старта процессов до первого ассерта. Общий контекст (один поток, --no-isolate / pool: 'threads' с выключенной изоляцией) быстр, но протекает состоянием между тестами в одном файле. Сеньорский баланс — изолировать состояние дёшево, а не дорого: сбрасывай синглтон в beforeEach, откатывай БД в afterEach, а дорогую изоляцию процессов держи для тех немногих наборов, что реально мутируют глобальное состояние модулей и не чистятся на месте.

Параллельная изоляция БД: откат, схема-на-воркер или контейнеры

Тесты, бьющие в настоящую БД параллельно, — сложнейшая задача изоляции, потому что БД по определению есть общее изменяемое состояние. Есть три стратегии, меняющие скорость на верность. Транзакция на тест, откатываемая в конце: каждый тест открывает транзакцию, делает свои записи, а фикстура откатывает в тирдауне, так что ничего не сохраняется — это самое быстрое, стоит примерно 1–3 мс настройки БД на тест, и тесты не видят строк друг друга. Его предел: нельзя протестировать ничего, зависящего от настоящего коммита — триггеры, срабатывающие на COMMIT, отложенные ограничения, видимость между соединениями или код, открывающий свою транзакцию. Схема или база на воркер: каждый параллельный воркер получает своё пространство имён и обрезает таблицы между тестами; truncate-all бежит за десятки миллисекунд, медленнее отката, но способен тестировать настоящие коммиты, при полной изоляции воркеров друг от друга. Эфемерные контейнеры (testcontainers): поднять свежую БД на воркер или на набор — максимальная верность (точная версия движка, настоящие расширения), но старт меряется секундами, так что их запускают куда меньше и амортизируют по многим тестам.

// transaction-per-test fixture (Postgres + a pool): fast, auto-clean, no leaks
import { test as base } from "vitest";
import { pool } from "../src/db.js";

export const test = base.extend({
  db: async ({}, use) => {
    const client = await pool.connect();
    await client.query("BEGIN");
    await use(client);          // the test runs inside this open transaction
    await client.query("ROLLBACK"); // every write vanishes — next test sees a clean DB
    client.release();
  },
});

// usage: each test is hermetic without truncating or restarting anything
test("inserts a user", async ({ db }) => {
  await db.query("INSERT INTO users(email) VALUES('a@x.io')");
  const { rows } = await db.query("SELECT count(*) FROM users");
  expect(rows[0].count).toBe("1"); // 1, regardless of parallel tests
});

Режим отказа: ретраи, которые маскируют флак

Вот как флакающий тест убивает деплой. Тест проходит в 80% случаев — реальная гонка 1 к 5, скажем, неотожданный промис, чья запись садится после ассерта, или протёкший таймер, держащий цикл событий живым в следующий тест. Кто-то, устав от красного CI, ставит retries: 3. Теперь тест зелёный: вероятность, что все четыре попытки упадут, — 0.2⁴ ≈ 0.16%, так что CI «починен». Это не так — эффективная доля отказов в 4% (один прогон из ~625 всё ещё красный) теперь невидима, и хуже того, лежащая под ней гонка тоже невидима. Месяцами набор зелёный. Потом гонка, симптомом которой был флак — неотожданная запись, зависимость от порядка, — проявляется в проде на деплое, в худший возможный момент, и ни один тест на неё не указал. Ретраи не починили флак; они спрятали баг, о котором флак докладывал.

Вариант с асинхронной протечкой острее: тест резолвится и докладывает «зелёно» до того, как его фоновая работа кончилась — fire-and-forget void doStuff(), таймер, который он не очистил. Эта работа потом бежит во время следующего теста, мутируя общее состояние и портя несвязанный ассерт. Сбой всплывает не в том тесте, и потому за ними так бесит гоняться. Детект механичен, не геройский: запускай с --detectOpenHandles (Jest) или следи за предупреждениями node --test об открытых дескрипторах / «не завершился», что указывают на таймер или сокет, ещё живой на выходе; запускай тесты в случайном порядке (--sequence.shuffle / --randomize), чтобы зависимость от порядка всплыла падением, а не везучим проходом; и относись к флаку как к багу — помести его в карантин (помечен пропущенным/известно-флакающим, вне критического пути) и чини корневую причину, а не заклеивай бюджетом ретраев, отмывающим реальную долю отказов в зелёную галочку.