Мета
Ключові завдання unit-тестів:
- Запобігати регресіям. Швидко виявляти помилки, які виникли після змін у коді.
- Підвищувати довіру до рефакторингу. Дозволяти змінювати реалізацію без страху зламати поведінку.
- Документувати поведінку системи. Тести виконують роль живої документації — вони показують очікувані сценарії використання модулів.
- Сприяти модульності та чистоті архітектури. Неможливо написати якісний unit-тест, якщо код не розділено на незалежні одиниці.
- Підвищувати ефективність розробки. Завдяки швидкому зворотному зв’язку, дефекти виявляються до інтеграційної стадії.
Unit-тести охоплюють окремі незалежні одиниці коду, які можна виконати без повного запуску системи.
У фронтенд-проєктах такими одиницями є:
| Тип | Приклади | Особливості тестування |
|---|---|---|
| Функції / утиліти | pure functions, форматери, калькулятори, фільтри, парсери | Без побічних ефектів, перевіряється вхід → вихід. |
| Кастомні хуки (React) | useFetchData, usePagination, useToggle… | Тестуємо через поведінку стану та ефектів, за потреби з моками залежностей (API, таймерів). |
| Компоненти UI | кнопки, поля вводу, модалки, дропдауни | Тестуємо публічну поведінку (інтерфейс користувача), а не внутрішній стан. Наприклад при перевірці модалки ми перевіряємо чи вона видима, а не його state isOpen = true. |
| Класи/сервіси | SDK модулі, обгортки над API, адаптери | Тестуються через методи й контракти, без реальної мережі (через моки). |
| Бізнес-логіка | обчислення, валідації, трансформації даних | Розділяється на чисті функції й тестується незалежно від UI. |
Межі (Out of Scope)
Section titled “Межі (Out of Scope)”Unit-тести не замінюють інші види тестування.
Їхня мета — гарантувати, що в межах одного модуля все працює очікувано.
Не охоплюється unit-тестами:
- Комунікація між модулями/сервісами;
- Сумісність з реальними браузерами чи пристроями;
- UX-поведінка (анімації, верстка, responsive layout);
- Повна логіка користувацьких флоу (login, checkout, тощо).
Unit-тест — це тест ізоляції. Якщо тест вимагає реального бекенду, роутера або DOM — це вже інтеграційний рівень.
Детальніше про межі unit тестування в розділі:
Терміни
Section titled “Терміни”У контексті нашої політики:
Unit — найменша функціональна одиниця коду, яку можна протестувати ізольовано, незалежно від інших частин системи.
Unit-тест — автоматизований тест, що перевіряє одну таку одиницю на основі:
- передбачених вхідних даних,
- очікуваних результатів або побічних ефектів,
- контрольованого середовища.
Життєвий цикл unit-тестів у процесі розробки:
- Створення/оновлення коду → додаємо або змінюємо unit-тести.
- Локальний прогін → кожен розробник запускає тести перед комітом.
- CI-перевірка → тести запускаються автоматично при кожному merge request.
- Регулярна перевірка стабільності → у разі флейків* тест або переписується, або ізолюється.
Вимірювані результати
Section titled “Вимірювані результати”Щоб оцінити ефективність unit-тестів, встановлюються такі метрики:
| Показник | Мета |
|---|---|
| Coverage (покриття) | ≥ 80% для основних пакетів, ≥ 90% для критичної бізнес-логіки |
| Час виконання | < 30 секунд локально; < 2 хвилин у CI |
| Flaky tests rate | < 2% від загальної кількості |
| Час на написання тестів | не перевищує 25% від часу на реалізацію фічі |
Ключові принципи
Section titled “Ключові принципи”- Один тест — одна поведінка.
- Тести мають бути стабільними (без флейків, залежності від часу, рандому, DOM).
- Тести мають бути швидкими — запускаються миттєво локально.
- Код має бути тестованим за своєю природою, а не через складні моки.
- Тести — це частина коду бази, вони проходять рев’ю так само як і основний код.
Більше інформації що до організації коду в розділі: