Тестирование хуков и контекста: renderHook, фейковые таймеры, устаревшие снимки

Что на самом деле делает renderHook

Хуки не работают вне компонента — Правила React это физика, а не стиль. renderHook (поставляется в @testing-library/react) строит минимальную легальную физическую лабораторию: монтирует одноразовый компонент-хост, вызывает в нём ваш хук с initialProps и копирует возвращаемое значение хука в result.current после каждого закоммиченного рендера. Больше ничего особенного — именно поэтому API имеет такую форму:

const { result, rerender, unmount } = renderHook(
  ({ userId }) => usePermissions(userId),
  {
    initialProps: { userId: "u1" },
    wrapper: ({ children }) => (
      <PermissionsProvider value={stubPermissions}>{children}</PermissionsProvider>
    ),
  },
);

rerender({ userId: "u2" });           // перерендеривает хост с новыми пропсами
expect(result.current.canEdit).toBe(false);
unmount();                            // запускает cleanup эффектов — тестируйте и их

wrapper — точка внедрения провайдеров, и в ней спрятано проектное решение: передавайте стабовое значение провайдера — простой объект, реализующий контракт контекста, — а не vi.mock модуля провайдера. Стабовое значение прогоняет настоящую проводку useContext и переживает рефакторинги провайдера; мок модуля привязывает тест к путям файлов и форме экспортов. Для контекста вроде query-клиента правило острее: создавайте свежий клиент на каждый тест внутри wrapper, иначе закешированные данные текут между тестами и фабрикуют зависимость от порядка.

Когда хуку вообще положен собственный тест? Тестируйте хук напрямую, когда он и есть публичный контракт — общий usePagination, потребляемый двенадцатью командами, заслуживает контрактных тестов независимо от любого потребителя. Когда хук существует ради одного компонента — тестируйте компонент: тест хука может оставаться зелёным при сломанной интеграции (неверная протяжка пропсов, тайминг рендера), а сеньорский сьют тратит бюджет там, где живёт видимый пользователю контракт.

Чтение result.current: идентичность, а не тайминг

result.current — свойство, которое харнесс переприсваивает после каждого коммита. Когда видите в тесте деструктуризацию result в начале и чтение из неё позже — флагуйте сразу: это самый распространённый скрытый баг в сьютах с хуками. Три следствия, каждое — пункт код-ревью. Первое — никогда не деструктурируйте: const { current } = result (или сохранённое «на потом» const value = result.current) замораживает выдачу одного рендера; каждая проверка после следующего обновления состояния читает историю. Правильная идиома скучно повторяется: result.current.x в каждой точке чтения, потому что каждое чтение должно наблюдать последний коммит. Второе — обновлениям нужен act: вызов result.current.save() вне act запускает обновление без детерминированного флаша (и предупреждает); оборачивайте меняющие состояние вызовы, await асинхронные. Третье — после unmount() result.current хранит последнее закоммиченное значение: это удобно для проверки финального состояния, но «чтение без ошибки» не доказывает, что хук жив; unmount на самом деле проверяет cleanup — интервалы очищены, подписки закрыты, висящий дебаунс сброшен или отменён — то, что обещает ваш контракт.

Фейковые таймеры, дебаунс и дедлок user-event

Дебаунс- или интервальный хук, тестируемый по реальным часам, стоит реальные секунды на тест и всё равно флейкает под нагрузкой CI. Фейковые таймеры делают время управляемым входом: vi.useFakeTimers() подменяет глобальные функции таймеров виртуальными часами, а vi.advanceTimersByTime(800) выстреливает ровно те колбэки, что подошли в этом окне, — детерминированно, мгновенно, независимо от нагрузки. Дисциплина вокруг них:

it("сохраняет один раз после 800 мс тишины", async () => {
  vi.useFakeTimers();
  const user = userEvent.setup({ advanceTimers: vi.advanceTimersByTime });
  render(<Editor />);

  await user.type(screen.getByRole("textbox"), "draft");

  act(() => { vi.advanceTimersByTime(799); });
  expect(saveSpy).not.toHaveBeenCalled();      // граница: ничего на 799

  act(() => { vi.advanceTimersByTime(1); });
  expect(saveSpy).toHaveBeenCalledTimes(1);    // срабатывает ровно на 800

  vi.useRealTimers();                          // всегда восстанавливайте — надёжнее в afterEach
});

Опция advanceTimers — разрушитель дедлока из Hook: user-event темпирует свои цепочки событий через setTimeout, поэтому под замороженными фейковыми часами каждый await user.type(...) ждёт вечно, пока user-event не научат продвигать часы самому. Прописывайте advanceTimers: vi.advanceTimersByTime при setup — каждая команда, взявшая фейковые таймеры без этого, теряет день на повисшем тесте. Паттерн граничных проверок (799, затем 1) и делает дебаунс-тест стоящим: он пиннит контракт — срабатывает один раз, срабатывает в дедлайн, не срабатывает раньше, — а не «когда-нибудь вызвался». Два честных предостережения не дают технике укусить в ответ. Фейковые таймеры подделывают таймеры, а не микротаски: продолжения зарезолвленных промисов по-прежнему идут через реальную очередь микротасок, поэтому advanceTimersByTime внутри act плюс await после — форма, дающая стечь обеим очередям. И утёкшие фейковые часы — заразитель всего сьюта: восстанавливайте в afterEach(() => vi.useRealTimers()), потому что waitFor следующего теста опрашивает через тот самый setTimeout, который вы заморозили, и его секундный бюджет даже не начинает тикать.