Назад до блогу

E2E‑автоматизація без “flaky”: Playwright/Cypress, тест‑дані, стабільність та швидкість

Як побудувати E2E так, щоб їм довіряли: ізоляція, тест‑дані, стабільні локатори, боротьба з flaky, паралелізація та правила запуску в CI.

18 лют. 2026 р.

Чому E2E тести часто стають “flaky”

Проблема рідко в інструменті. Найчастіше винні: спільні тест‑дані, залежність від зовнішніх сервісів, нестабільні селектори, очікування “таймаутами” і різні середовища.

1) Обмеж кількість сценаріїв

  • Автоматизуй тільки критичні флоу (5–20).
  • Детальні перевірки перенеси у unit/integration.

2) Тест‑дані та ізоляція

  • Кожен тест створює свої дані через API/fixtures.
  • Не залежати від “вчорашніх” даних у БД.
  • Контрольовані зовнішні інтеграції: моки/стаби.

3) Стабільні локатори

Використовуй data-testid або role/aria‑локатори. CSS‑класи й тексти — часта причина крихкості.

4) Анти‑flaky правила

  • Очікування по стану (visible/enabled), а не по “sleep”.
  • Одна таймзона, контрольований час (freeze time) для критичних кейсів.
  • Артефакти на фейлі: скрін/відео/трейс.

5) Запуск у CI

  • Паралелізація шардінгом.
  • Окремий job для E2E, щоб не блокувати швидкі перевірки.
  • Ретраї: 0–1 максимум, інакше ви ховаєте проблему.

Підсумок

Стабільні E2E — це дисципліна: дані, локатори, ізоляція, артефакти і правильний CI. Тоді тести стають “зеленим світлом” на реліз.

Релевантні статті