Запропонувати правкуПокращити цю статтюДопрацюйте відповідь до «Чому е2е тестів не повинно бути багато?». Ваші зміни проходять модерацію перед публікацією.Потрібне підтвердженняКонтентЩо ви змінюєте🇺🇸EN🇺🇦UAПереглядЗаголовок (UA)Коротка відповідь (UA)**E2E-тести** не повинні бути численними, бо вони найдорожчі, найповільніші і найкрихкіші серед усіх типів тестів. **Ключове:** E2E мають покривати лише ключові користувацькі сценарії, а решту перевірок вигідніше закривати юніт- і інтеграційними тестами, які швидші, стабільніші й дешевші.Показується над повною відповіддю для швидкого нагадування.Відповідь (UA)ЗображенняТому що E2E-тести найдорожчі, найповільніші і найкрихкіші серед усіх типів тестів. ## Причини 1. **Повільні прогони** Кожен тест піднімає браузер, переходить сторінками, чекає на рендер, виконує реальні дії. Один тест може займати секунди або десятки секунд, це в десятки разів повільніше за юніти. 2. **Висока вартість підтримки** Найменші зміни в інтерфейсі, текстах, верстці або мережевих сценаріях можуть ламати тест. Чим їх більше, тим більше часу йде на полагодження. 3. **Залежність від оточення** E2E залежать від мережі, бази, API, інфраструктури. Будь-яка нестабільність робить їх flaky. Масові E2E = масові хибні падіння. 4. **Перекривають одні й ті самі сценарії** E2E часто перевіряють схожі користувацькі флоу. Якщо їх багато, з'являється дублювання, яке не додає цінності, а лише сповільнює процес. 5. **Вбивають швидкість команди** Довгі прогони → тривалий feedback loop → повільне ухвалення рішень → сповільнення розробки. **Суть:** E2E мають покривати лише ключові користувацькі сценарії. Іншу перевірку (логіка, інтеграції, стани) вигідніше закривати юніт- і інтеграційними тестами, тому що вони швидші, стабільніші й дешевші.Для рев’юераПримітка для модератора (необов’язково)Бачить лише модератор. Прискорює рев’ю.