Що саме ми тестуємо (і чого не тестуємо)

Пріоритети покриття (risk-based)

Тип	Пріоритет
Критична бізнес-логіка (утиліти/сервіси/валідації)	must have
Варіативні UI-компоненти (умовні гілки, стани, доступи)	high
Кастомні хуки (стан, таймери, мережа)	high
SDK/API-клієнти (формування запитів/помилки/ретраї)	high
Локальні інтеграції (форма + валідація + сабміт)	medium
Прості “проксі-компоненти” без логіки	low

ЩО ТЕСТУЄМО — за типами

Чисті функції / утиліти

• Правильні результати для нормальних, межових і помилкових входів.
• Ідемпотентність/детермінізм.
• Локалі/часові зони, нульові/порожні значення.

Приклад: форматер дат → набір параметризованих it.each з різними TZ/locale.

Кастомні хуки

• Початковий стан і переходи станів (після подій/викликів).
• Асинхронність: лоадінг → успіх/помилка; скасування запиту; повторна спроба.
• Таймери, debounce/throttle (через vi.useFakeTimers()).
• Реакція на залежності (зміна пропів/контексту).

Не тестуємо внутрішні useState напряму; перевіряємо ефект (що хук повертає).

UI-компоненти (через поведінку)

• Відображення публічних станів: disabled, aria-busy, aria-expanded, error.
• Взаємодії: кліки, типінг, навігація з клавіатури, hotkeys.
• Умовні гілки: різні пропи/ролі/пермішени → різна поведінка/контент.
• Побічні ефекти: виклики колбеків/сервісів, показ toast, зміна фокуса.
• Доступність (a11y): правильні role/name, керованість з клавіатури.

Не тестуємо дрібні “ехо” - “рендерить children”, “виводить проп title”, якщо це не пов’язано з умовною логікою або a11y.

Форми

• Валідація: синхронна/асинхронна; відображення помилок; disabled кнопки.
• Сабміт: правильний payload, поведінка на 2xx/4xx/5xx.
• Маски/форматування полів, required/aria-invalid.
• Edge-кейси: порожні значення, дуже довгі строки, нестандартні символи.

SDK / API-клієнти / адаптери

• Формування URL/headers/body; обробка помилок; таймаути/ретраї.
• Мапінг відповідей у доменні моделі.
• Поведінка при 401/403 (напр., тригер логауту/refresh).

Тут доречні node-тести без jsdom.

Глобальний стан (Redux/Zustand/Context)

• Ред’юсери як чисті функції (вхід → вихід).
• Селектори (правильно обчислюють дані).
• Ефекти/сайд-ефекти — через моки залежностей.

ЧОГО НЕ ТЕСТУЄМО unit-тестами

• Треті бібліотеки (React, router, UI-кіти) — лише наші обгортки/інтеграції.
• Стилі/верстка/піксель-перфект — це візуальні регрес-тести.
• Великі снепшоти DOM — ламкі та малокорисні.
• Реальна мережа/браузер — використовуємо MSW/jsdom.
• Глибокі внутрішні деталі (внутрішній state, приватні функції компонентів).
• E2E-флоу (роутинг, автологін, багатокрокові сценарії) — це Playwright.

Мінімальні чек-листи на кейс

Компонент із кліком та асинком

• Кнопка доступна за role name.
• disabled/aria-busy змінюються під час запиту.
• Викликається сервіс із правильним payload.
• На успіх — показується успішний сигнал (toast/текст).
• На помилку — помилка + повторна спроба працює.

Форма

• Помилки валідації видимі та читабельні (aria-*).
• Сабміт заборонений, якщо форма невалідна.
• Відправляється коректний payload.
• Серверні помилки мапляться на поля або загальний алерт.

Технічні практики

• Селектори: віддаємо перевагу getByRole/name над getByTestId.
• Асинхронність: await findBy... / waitFor, без “магічних” таймаутів.
• Параметризовані тести: it.each для наборів вхідних даних.
• Фікстури: малі, самодостатні; уникаємо продакшн-дампів.
• Моки: тільки для побічних ефектів (API/час/сторедж). Мінімізувати кількість.

Покриття

Тип	Відсоток
Утиліти/бізнес-логіка	90%+
Хуки	85%+
Компоненти	70–80% (логіку винести нагору)
Репозиторій сумарно	80%+

Короткі DO / DON’T

DO

• Тестуй поведінку й варіативність.
• Пиши малі, ізольовані тести.
• Винось логіку в утиліти/хуки/сервіси.
• Використовуй MSW/моки для ефектів.
• Перевіряй a11y (role, name, focus order).

DON’T

• Не знімай великі снепшоти.
• Не чіпляйся до приватного state/імплементації.
• Не викликай реальний бекенд/час/рандом.
• Не використовуй getByTestId, якщо можна byRole/byText.