Какие стратегии работы с явными и неявными ожиданиями в автотестах?

Что проверяют

Знаете ли вы, как ожидания в Selenium и похожих инструментах влияют на стабильность тестов и чем их заменить вместо Thread.sleep. Следом часто спрашивают, почему нельзя смешивать неявное и явное ожидание и как вы боролись с нестабильными тестами.

Как отвечать

Разведите три механизма:

• неявное ожидание: driver.manage().timeouts().implicitlyWait(Duration.ofSeconds(10)). Задаётся один раз на драйвер и действует на каждый findElement: драйвер повторяет поиск, пока элемент не появится в DOM. Проверяет только наличие, а не видимость или кликабельность;
• явное ожидание: WebDriverWait плюс условие из ExpectedConditions, например elementToBeClickable или invisibilityOfElementLocated для спиннера. Ждёт конкретного состояния в конкретном месте;
• FluentWait: то же явное ожидание с настройкой интервала опроса и списком игнорируемых исключений, например StaleElementReferenceException.

Рабочая стратегия: неявное ожидание в ноль, явные ожидания внутри методов Page Object, таймауты в конфиге, а не цифрами по коду.

Покажите, что знаете современные инструменты. Playwright ждёт сам: перед кликом проверяет, что элемент видим, стабилен и доступен, а expect(locator).toBeVisible() повторяет проверку до таймаута, по умолчанию 5 секунд. В Selenide и Cypress такое же автоожидание, по умолчанию 4 секунды.

Где спотыкаются

Ставят Thread.sleep(3000). На быстрой машине тест тратит время впустую, на медленном стенде всё равно падает.

Смешивают неявное и явное ожидание. Документация Selenium прямо предупреждает, что это даёт непредсказуемые таймауты: внутри явного ожидания каждый поиск ещё и ждёт неявно.

Ждут появления элемента в DOM и сразу кликают, пока он перекрыт оверлеем или ещё анимируется. Итог: ElementClickInterceptedException. В Playwright похожая ошибка: ждать networkidle, который сама документация не рекомендует.