Рівень тесту і роль тесту — різні класифікації
Unit, integration, API та E2E описують рівень перевірки. Smoke і regression описують роль у наборі. Тому E2E може бути smoke, а regression-тест може існувати на unit, integration, API або E2E-рівні.
| Роль | Призначення |
|---|---|
| Smoke | Швидко підтвердити, що критична система загалом працює |
| Regression | Закріпити конкретний дефект, який уже виникав |
| E2E | Пройти повний користувацький шлях через систему |
Smoke має бути коротким і стабільним
- Перевіряйте мінімальний набір критичних сигналів.
- Можна почати з health endpoint і першої сторінки замовлень.
- Не перетворюйте smoke на весь функціонал продукту.
- Швидкий стабільний набір корисніший за довгий крихкий сценарій.
- Після змін перевіряйте, що основний сервіс доступний.
Regression зберігає памʼять про дефект
Якщо подвійний refund створював два записи, regression-тест має повторити операцію й перевірити, що в сховищі залишається один запис. Рівень тесту визначається місцем прояву проблеми.
- Відтворіть проблему.
- Напишіть тест, який показує неправильну поведінку.
- Внесіть fix.
- Переконайтеся, що той самий тест проходить.
- Залиште тест у репозиторії для наступних запусків.
E2E потрібен для високого бізнес-ризику
E2E проходить шлях користувача через UI, backend та повʼязані компоненти. Він доречний для checkout, підтвердження refund оператором або входу до адміністративної панелі, якщо дефект проявляється лише в повному потоці.
Не кожна UI-деталь потребує E2E. Надмірний E2E збільшує час запуску, крихкість і складність діагностики.
Не маскуйте flaky-тести повторним запуском
| Причина нестабільності | Контроль |
|---|---|
| Час і випадковість | Фіксувати clock і seed |
| Мережа або зовнішні сервіси | Ізолювати залежність або використовувати контрольований stub |
| Анімації та повільні відповіді | Надійні очікування замість sleep |
| Крихкі селектори | Стабільні семантичні селектори |
| Порядок тестів | Незалежні фікстури й ізоляція стану |
Канонічне джерело уроку · JavaRush
Відкрити матеріал JavaRush