Как стабилизируют флаки-тесты (Flaky tests)?

Флаки-тесты — это кошмар автоматизации. В моей практике борьба с ними строится на выявлении первопричины и применении комбинации подходов.

Основные стратегии стабилизации:

1. Надёжные ожидания вместо Thread.sleep(): Использую явные ожидания для конкретных условий.

   // Selenium WebDriver с Java
   WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
   wait.until(ExpectedConditions.elementToBeClickable(By.cssSelector("[data-qa='save-btn']"))).click();

   Для сложных SPA-приложений иногда пишу кастомные условия ожидания, например, для завершения анимаций или фоновых API-запросов.

2. Изоляция тестовых данных: Каждый тест создаёт свои уникальные данные (например, пользователя с email test+<timestamp>@domain.com) и очищает их в @AfterEach/@AfterMethod методе. Это предотвращает конфликты при параллельном запуске.

3. Идемпотентность тестов: Тест должен давать одинаковый результат при многократном запуске. Если тест меняет глобальное состояние, я переписываю его, чтобы откатывать изменения.

4. Мокирование внешних сервисов: Нестабильные сторонние API (платёжные шлюзы, SMS-сервисы) заменяю на стабы с помощью WireMock или MockServer. Это даёт полный контроль над ответами и задержками.

5. Анализ и логирование: При падении флаки-теста логирую всё: URL, HTML-снимок (page source), скриншот, состояние cookies/localStorage. Часто проблема оказывается в неучтённом модальном окне или устаревшей сессии.

6. Retry — последнее средство: Перезапуск упавшего теста (@Retry в TestNG) — это пластырь, а не лечение. Я настраиваю retry только для небольшого набора высокоуровневых E2E-тестов, где root-cause — действительно внешняя нестабильность, и только после исчерпания других вариантов.

Пример подхода: На прошлом проекте мы внедрили стабильность-чек в CI/CD: если тест падает в >30% случайных запусков, он автоматически помечается как @Flaky и исключается из блокирующей пайплайны, пока проблема не будет исследована и исправлена.