Код-рев’ю тестів

Мета

Забезпечити, щоб тести:

• перевіряли поведінку публічних контрактів, а не імплементаційні деталі;
• були стабільними, швидкими, ізольованими та підтримуваними;
• приносили релевантне покриття там, де це дає цінність;

Коли обов’язкове

• Будь-які зміни в бізнес-логіці/компонентах → супровідні тести обов’язкові.
• Зміни у тест-інфраструктурі (setup, MSW handlers, factories).

Ролі

• Автор PR: довести коректність/стабільність; надати контекст і артефакти (лог, репорти).
• Рев’юер: перевірити достатність, релевантність, якість та ризики регресій.

Чек-лист для автора PR (тільки про тести)

• Покриття змін:
  • є тести для нової/зміненої поведінки;
  • видалені тести - [ ] аргументовано;
• Правильна піраміда:
  • unit там, де можливо;
  • інтеграційні - [ ] коли перевіряємо контракт між модулями;
  • E2E - [ ] не підміняє unit;
• AAA/Behaviour-first:
  • Arrange-Act-Assert;
  • тести читаються як сценарії користувача/споживача API.
• Ізоляція:
  • без прихованої залежності між тестами;
  • reset/clear мock’ів у afterEach;
• Детермінізм:
  • без довільних таймаутів;
  • vi.useFakeTimers()/vi.advanceTimersByTime() за потреби;
  • будь-яка рандомізація - [ ] із seed;
• Асинхронщина:
  • await на всі async дії;
  • waitFor лише за реальної необхідності;
  • без “голих” setTimeout;
• Моки/стаби:
  • мокаємо лише те, чим не володіємо (мережа/час/браузерні API);
  • не мокаємо те, що тестуємо;
• MSW:
  • хендлери визначені локально до тест-сьюту або у factory;
  • перевіряємо як успіх, так і помилки/таймаути;
• Дані:
  • використовуються factories/builders, а не “магічні” значення;
  • дані мінімальні, але реалістичні;
• RTL (jsdom): селектори за ролями/іменами, а не getByTestId (окрім технічних випадків).
• Snapshots:
  • малі, стабільні; оновлення - [ ] з поясненням;
  • за можливості - [ ] точкові assertions замість великих снапшотів;
• Швидкість: сьют < 2с локально; важкі випадки - [ ] параметризовані/розбиті.
• Шум:
  • немає console.log/error у зеленому прогоні;
  • помилки глушаться/перевіряються очікуваннями;
• CI-артефакти:
  • JUnit та Cobertura генеруються;
  • локально проходить pnpm vitest run --coverage.
• Оточення: TZ=UTC, стабільна локаль, відсутні реальні мережеві запити.
• Guard-rail’и:
  • немає test.only/describe.only;
  • test.skip - тільки з TODO-посиланням;

Чек-лист для рев’юера (тільки про тести)

Обсяг і фокус

• Чи покрито саме змінену поведінку? Чи є тести на негативні сценарії та крайні кейси?
• Чи не тестуються внутрішні деталі (приватні функції, внутрішній стан), де краще перевірити публічний контракт?

Якість реалізації

• Читабельність: AAA, мінімум дублів, осмислені назви.
• Ізоляція: немає прихованого стану між тестами, чисті моки/DOM після afterEach.
• Детермінізм: без “sleep”, коректне використання fake timers, асинхронні дії - через await.
• Моки: не надмірні, мережа/дата/рандом - під контролем, MSW-хендлери відображають реальні API-контракти.
• Дані: factories/builders, немає «хрустких» снапшотів на величезні дерева DOM.

Релевантність і цінність

• Чи покращує тест набір регресійної безпеки? Чи не дублює інші тести?
• Снапшоти: чи є користь від них, чи не стали “спамом”?
• Перформанс: чи не надто важкий сьют, чи можна параметризувати/розбити?

Інфраструктура

• Репорти JUnit/Cobertura додаються артефактами, немає “шуму” у логах.
• Немає only, skip - авмотивований і зафіксований задачею.
• Для Date, Intl, crypto, random - застосовано стабілізацію (моки/seed).

Що вважаємо блокерами (Request changes)

• Відсутні тести на нову/змінену поведінку або відсутні негативні/edge кейси.
• Флакіність: використання довільних таймаутів, відсутність контролю над часом/мережею.
• Тестуємо імплементаційні деталі замість контрактів, надмірні/крихкі снапшоти.
• Витоки стану між тестами, відсутній reset моків/DOM.
• Реальні мережеві запити в unit/integ, відсутні MSW-хендлери.
• Відсутні CI-артефакти (JUnit/Coverage) для відповідних job.

Що вважаємо некритичним (Non-blocking, коментарі)

• Іменування, дрібні покращення читабельності.
• Мікро-рефакторинги factories/fixtures.
• Альтернативні стилі assertions за наявності поведінкового еквівалента.