Фронтенд-код ламається так само, як серверний: форма перестає відправлятися, фільтр показує не ті дані, кнопка «Оплатити» неактивна. Без тестів про це дізнаються користувачі, а кожен рефакторинг стає ризиком.
Рівні тестів:
| Рівень | Що перевіряє | Інструменти | Швидкість |
|---|---|---|---|
| unit | одна функція чи модуль окремо: форматування ціни, валідація, розрахунок кошика | Vitest, Jest | мілісекунди |
| компонентні / інтеграційні | кілька частин разом у DOM: компонент з формою, відправка, повідомлення про помилку | Vitest + Testing Library, jsdom чи справжній браузер | десятки мілісекунд |
| end-to-end (E2E) | увесь застосунок у справжньому браузері з бекендом: вхід, оформлення замовлення | Playwright, Cypress, Pest browser tests | секунди |
Піраміда радить багато дешевих unit-тестів, менше інтеграційних і кілька E2E: що вище рівень, то тест повільніший, крихкіший і дорожчий у підтримці.
«Тестовий трофей» (Kent C. Dodds) - альтернативний погляд для фронтенду: найбільше користі дають інтеграційні тести, бо unit-тести окремих функцій інтерфейсу часто перевіряють деталі реалізації, а не те, що бачить користувач. Основа трофея - статичний аналіз: TypeScript і ESLint ловлять цілий клас помилок без жодного тесту.
Що тестувати насамперед:
- чисту логіку без DOM: розрахунки, перетворення даних, парсинг - найдешевші й найстабільніші тести;
- критичні сценарії користувача (вхід, оплата, відправка форми) - кількома E2E-тестами;
- місця, де вже були баги: тест на баг гарантує, що він не повернеться.
Що не тестувати:
- бібліотеки й фреймворк - вони протестовані авторами;
- точну розмітку й стилі - такі тести падають від кожної зміни дизайну;
- приватні деталі реалізації, які користувач не бачить.
Для Laravel-проєкту: бекенд покривають Pest-тестами, а для фронтенду часто достатньо unit-тестів складної логіки в Vitest і браузерних тестів основних сторінок - вони перевіряють і JavaScript, і серверну частину одночасно.
Докладніше в документації: Martin Fowler: The Practical Test Pyramid