Тести мають давати впевненість і не заважати змінювати код. Тести, що ламаються від кожного рефакторингу, але пропускають справжні помилки, - гірші за їх відсутність: команда звикає їх «оновлювати не дивлячись».
Чого не тестувати - деталі реалізації:
- внутрішній стан (
useState), назви змінних, приватні функції компонента; - порядок і кількість викликів хуків, кількість рендерів (крім спеціальних тестів продуктивності);
- структуру розмітки й класи CSS -
container.querySelector('.card > div:nth-child(2)')ламається від будь-якої зміни верстки; - поведінку бібліотек - що React рендерить, що роутер переходить, що TanStack Query кешує. Це вже протестовано;
- дрібні компоненти без логіки (обгортка над
<button>з класами) - їх перевіряють тести компонентів, що їх використовують.
Що тестувати: те, що бачить і робить користувач, і контракт компонента - як він реагує на props і дії, що відправляє на сервер, що показує при помилці, порожньому списку, завантаженні.
Знімкові тести (toMatchSnapshot) зберігають весь відрендерений HTML і порівнюють з ним при наступних запусках.
Чим вони небезпечні:
- ламаються від будь-якої зміни - нового класу, перенесеного атрибута, зміни тексту. Більшість падінь - не баги;
- «оновити всі знімки» (
-u) стає рутиною, і справжня регресія проходить разом з іншими змінами; - великі знімки ніхто не читає на рев'ю - дифф на 300 рядків розмітки;
- знімок фіксує поточну поведінку, а не правильну - якщо баг був при створенні знімка, тест його захищає.
Коли знімки доречні:
- маленькі й сфокусовані -
toMatchInlineSnapshotдля результату функції форматування, повідомлення про помилку, згенерованого фрагмента; - серіалізовані дані, а не розмітка: структура запиту до API, конфігурація.
Замість знімка сторінки - кілька явних перевірок того, що важливо:
expect(screen.getByRole('heading', { level: 1 })).toHaveTextContent('Вакансії');
expect(screen.getAllByRole('article')).toHaveLength(3);
expect(screen.getByRole('link', { name: 'Наступна сторінка' })).toHaveAttribute('href', '/jobs?page=2');
Візуальні регресійні тести (Playwright toHaveScreenshot, Chromatic) - окремий інструмент для перевірки вигляду, і тоді вони порівнюють зображення, а не HTML.
Покриття коду - корисний сигнал, а не мета: 100% покриття тестами деталей реалізації дає менше впевненості, ніж 70% поведінкових тестів.
Докладніше в документації: Testing Library: керівні принципи