Явные и неявные ожидания
Тема дорожной карты · QA-инженер
Обработка ожиданий в UI-тестах — один из наиболее важных и наиболее часто неправильно реализуемых аспектов написания надёжной автоматизации с Selenium, Playwright и Cypress, поскольку современные веб-приложения рендерят контент асинхронно и элементы могут быть недоступны в момент выполнения тестового действия. В Selenium WebDriver существуют три стратегии ожидания: implicit wait (глобальный таймаут опроса, устанавливаемый один раз на экземпляре WebDriver), explicit wait с использованием WebDriverWait и ExpectedConditions, таких как element_to_be_clickable или visibility_of_element_located, и Fluent Wait для пользовательских интервалов опроса и игнорируемых исключений — из этих вариантов рекомендуются explicit waits. Playwright решает проблему ожиданий архитектурно через встроенное автоожидание: каждый page.click(), page.fill() и expect(locator).toBeVisible() автоматически повторяются до тех пор, пока элемент не достигнет необходимого состояния доступности, устраняя необходимость ручных вызовов sleep(), вызывающих нестабильные тесты. Cypress аналогично использует модель очереди команд с автоматическими повторами при ассерциях, а все три фреймворка выигрывают от детерминированных CI/CD-сред — браузерных контейнеров на базе Docker с фиксированными ресурсами, — снижающих вариативность таймингов, вызванных особенностями среды и делающих ожидания непредсказуемыми.
Как это работает
Явные и неявные ожидания использует browser-automation тулы (Playwright, Cypress, Selenium) для управления реальными браузерами. Стабильные локаторы критичны: предпочитайте data-testid-атрибуты (добавляют разработчики), затем ARIA-роли + accessible names, потом текст, в крайнем случае CSS-селекторы. Используйте явные wait (await page.waitForSelector(...)), никогда sleep. Изоляция тестов: каждый создаёт свои данные или гонится на свежем state. Параллельно для скорости; в CI с retry-on-flake.
Когда применять
Playwright — для новых проектов (лучший DX, быстро, multi-browser, скриншоты/видео встроены). Мокайте сеть на границе (msw, Playwright route) — UI-тесты не должны зависеть от надёжности реального backend. Visual regression (Percy, Chromatic, Playwright snapshot) — для design-sensitive флоу. Тегайте тесты по скорости + критичности (@smoke, @regression); smoke — на каждый PR, regression — еженочно.
Типичные ошибки
Ловушки Явные и неявные ожидания: локаторы через автогенерированные CSS-классы (следующий деплой их ломает); общий test-state даёт зависимость от порядка; UI-тесты без параллелизма в CI (1-часовые прогоны тормозят команду); flake-тесты оставлены — один flake подрывает доверие ко всему suite (чините или удаляйте).