Почему ваши автотесты падают раз через раз: 5 причин flaky-тестов

Flaky-тесты — главный источник недоверия к автоматизации. По данным Google Testing Blog, около 1.5% всех зелёных пробегов в их CI содержали хотя бы один нестабильный фейл. И чаще всего проблема не в продукте, а в самом тесте.

⚠️ Implicit + explicit waits в одном проекте. Selenium документация прямо предупреждает: смешивать их нельзя. Implicit wait блокирует поиск элемента, explicit добавляет свою задержку — суммарный таймаут становится непредсказуемым. Оставляйте только WebDriverWait с явным условием.

⚠️ Тесты на Thread.sleep(3000). Это всегда либо мало (под нагрузкой CI), либо много (медленно). Замените на ожидание конкретного состояния DOM: elementToBeClickable, presenceOfElementLocated, textToBe.

⚠️ Зависимость от порядка тестов. Тест A создаёт юзера, тест B логинится тем же email. Если B запустился раньше — упало. Каждый тест должен быть полностью изолированным: своя фикстура с уникальным ID или setUp/tearDown с очисткой.

⚠️ Анимации и transitions. Тест жмёт кнопку, проверяет результат — но кнопка ещё в анимации появления. Решение: либо отключить CSS-анимации в тестовом окружении (* { animation: none !important; }), либо ждать aria-busy="false".

⚠️ Shared environment. Параллельный CI-раннер изменил данные посреди вашего теста. Используйте data isolation: namespacing по test id, transactional rollback в БД, или мок внешних API через WireMock/MSW.

Что делать прямо сейчас

✅ Запустите свой самый нестабильный тест 50 раз подряд — паттерн фейлов покажет тип проблемы.

✅ Retry на уровне раннера используйте ТОЛЬКО как временный костыль с тегом и задачей в Jira — иначе он замаскирует реальные баги.

✅ Отключите implicit wait глобально и посмотрите, какие тесты сразу попадают в красное — это ваши точки роста.

Подробнее: Martin Fowler — Eradicating Non-Determinism in Tests.