Почему фиксированная пауза делает тест нестабильным: ожидания в Playwright

Фиксированная пауза ломает UI-тест не потому, что сама по себе «плохая», а потому, что она ничего не знает о состоянии страницы. sleep ждёт ровно заданное время, даже если кнопка уже готова через 200 миллисекунд или, наоборот, появится позже. Из-за этого один и тот же тест то проходит, то падает: на быстром окружении он зря тормозит, на медленном — пытается проверить результат раньше нужного момента.

В Playwright надёжнее отталкиваться не от времени, а от наблюдаемого состояния. Для действия это готовность элемента к самому действию, а для проверки сценария — конкретный результат, который можно увидеть в DOM. Ниже разберём это на узком учебном случае и сразу выберем Python Playwright sync API: форма показывает кнопку только после отложенного изменения состояния, а итог отправки тоже появляется не мгновенно.

Какая готовность нужна действию

Когда тест пишет «подожди 2 секунды и нажми», он подменяет условие временем. Но клику не нужны именно 2 секунды. Ему нужно, чтобы элемент был найден однозначно, стал видимым, перестал двигаться, реально принимал событие мыши и не был disabled. Если хотя бы одно из этих условий ещё не выполнено, ранний клик превращается в угадывание.

В Playwright часть этой работы уже встроена в действия. Например, locator.click() не спешит нажимать мгновенно: сначала проверяет, что перед ним ровно тот элемент, который можно безопасно нажать. Это полезно по двум причинам. Во-первых, тест описывает намерение: «нажми кнопку, когда она станет готова», а не «подбери паузу». Во-вторых, если состояние так и не наступило, вы получаете понятную ошибку по таймауту, а не случайный успех после завышенного sleep.

Здесь важно разделять две вещи. Готовность к действию отвечает на вопрос «можно ли сейчас нажать?». Готовность результата отвечает на вопрос «произошло ли то, ради чего нажимали?». Даже если Playwright сам дождался кликабельности кнопки, он не обязан угадывать, какой текст должен появиться после отправки формы. Это уже задача явной проверки результата.

Учебный сценарий с отложенным состоянием

Учебный пример. Возьмём форму, где кнопка отправки сначала скрыта и отключена. После ввода email запускается отложенная проверка состояния формы, и только через 900 миллисекунд кнопка становится видимой и доступной. После нажатия результат тоже появляется не сразу, а через 700 миллисекунд. Это искусственный, но удобный сценарий: он показывает сразу две разные синхронизации — перед действием и после него.

Здесь легко сделать распространённую ошибку: добавить page.wait_for_timeout(500) после ввода и решить, что вопрос синхронизации закрыт. В нашем HTML такая пауза не воспроизводит проблему с кликом напрямую, потому что submit.click() в Playwright всё равно обычно дождётся готовности кнопки сам. Поэтому фиксированная пауза перед кликом здесь не столько «ломает» действие, сколько даёт ложное ощущение контроля и добавляет лишнее ожидание. А вот если после клика вы ещё и проверяете результат через такой же короткий sleep, тест уже становится нестабильным: итоговый текст появится позже.

Надёжнее описать именно то, что нужно увидеть. В нашем случае логика такая: заполнить поле, дождаться, что кнопка стала видимой и доступной, нажать её, затем проверить текст результата. Ниже — полный учебный пример на Python Playwright sync API с локальной разметкой, чтобы было видно исходные данные, действие и проверяемый итог.

from playwright.sync_api import sync_playwright, expect

HTML = """
<form>
  <label>Email <input id='email' /></label>
  <div id='status'>Ожидание ввода</div>
  <button id='submit' disabled style='display:none'>Отправить</button>
  <div id='result'></div>
</form>
<script>
  const email = document.getElementById('email');
  const status = document.getElementById('status');
  const submit = document.getElementById('submit');
  const result = document.getElementById('result');

  email.addEventListener('input', () => {
    status.textContent = 'Проверяем адрес';
    submit.disabled = true;
    submit.style.display = 'none';
    result.textContent = '';
    clearTimeout(window.__showButtonDelay);
    window.__showButtonDelay = setTimeout(() => {
      status.textContent = 'Адрес доступен';
      submit.style.display = 'inline-block';
      submit.disabled = false;
    }, 900);
  });

  submit.addEventListener('click', (event) => {
    event.preventDefault();
    status.textContent = 'Отправляем форму';
    clearTimeout(window.__submitDelay);
    window.__submitDelay = setTimeout(() => {
      result.textContent = 'Форма отправлена';
      status.textContent = 'Готово';
    }, 700);
  });
</script>
"""

with sync_playwright() as p:
    browser = p.chromium.launch()
    page = browser.new_page()
    page.set_content(HTML)

    page.locator('#email').fill('student@example.com')

    submit = page.locator('#submit')
    expect(submit).to_be_visible()
    expect(submit).to_be_enabled()
    submit.click()

    expect(page.locator('#result')).to_have_text('Форма отправлена')
    browser.close()

Проверяемое ожидание результата

В этом примере полезны два разных типа ожидания. Сначала мы ждём состояние, которое нужно для действия: кнопка должна стать видимой и доступной. Затем мы ждём состояние, которое подтверждает смысл сценария: после клика текст результата должен стать Форма отправлена. Это и есть замена «слепой» паузы на проверяемые условия.

Теперь видно, почему фиксированный sleep путает разные задачи. Пауза перед кликом не делает сам клик надёжнее, если у действия уже есть auto-waiting. Пауза после клика не знает, когда именно завершится отправка. В нашем учебном сценарии результат выставляется через 700 миллисекунд, поэтому wait_for_timeout(500) перед проверкой даст ложное падение, а wait_for_timeout(2000) просто замедлит каждый запуск без дополнительной пользы.

Ещё одна практическая деталь: явные ожидания через expect(...) удобнее для чтения, чем «магические» паузы. Через месяц вы всё ещё поймёте, что именно должен был увидеть тест: кнопку, которая стала доступной, и текст успешной отправки. А вот пауза на 1730 миллисекунд обычно не объясняет ничего, кроме того, что когда-то где-то сценарий падал.

Что автоматические ожидания не гарантируют

Автоматические ожидания в Playwright сильно сокращают число flaky-тестов, но они не читают замысел тестировщика. Они не знают, какой текст должен появиться после действия, сколько элементов должно стать в списке, завершилась ли фоновая операция и сохранены ли данные так, как вы ожидаете. Поэтому схема «кликнуть и сразу считать сценарий завершённым» остаётся ненадёжной.

Есть и более тонкий момент: иногда разработчики пытаются «исправить» нестабильность через принудительное действие с отключением части проверок. Это плохая замена нормальному ожиданию. Если элемент перекрыт, ещё двигается или не готов принять событие, принудительный клик маскирует симптом, а не объясняет, в каком состоянии реально находится интерфейс. Такой тест может пройти в одном запуске и дать сбой в другом уже по другой причине.

На практике полезно задавать себе короткий вопрос после каждого шага: что должно стать наблюдаемым, если предыдущий шаг действительно завершился? Для ввода это может быть доступная кнопка. Для отправки — текст, URL, число строк в таблице, значение поля. Пока ответ формулируется как «подождать ещё немного», тест остаётся зависимым от удачи и скорости окружения.

Как переписать нестабильный тест без sleep

Рабочий алгоритм короткий. Сначала найдите место, где пауза подменяет условие. Затем замените её на наблюдаемое состояние перед действием: видимость, доступность, нужный текст, количество элементов. После самого действия добавьте отдельную проверку результата, который подтверждает смысл шага. Если вы не можете назвать этот результат, проблема обычно не в Playwright, а в расплывчатом сценарии теста.

Для нашего учебного случая итог проверяется прозрачно. Исходные данные: после ввода email кнопка раскрывается через 900 миллисекунд, а текст успеха появляется через 700 миллисекунд после клика. Действия: заполнить поле, дождаться видимой и доступной кнопки, нажать. Проверяемый результат: блок #result получил текст Форма отправлена. Это лучше фиксированной паузы по трём причинам: тест быстрее на удачных прогонах, падает по понятной причине и легче поддерживается, когда интерфейс меняется.

Если хотите потренировать такие сценарии системно, в сохранённом описании каталога курса «Автоматизированное тестирование на Python: Путь от Junior до Senior» есть отдельный модуль про UI-тестирование: Playwright, Page Object Model и ожидания. Официальная страница курса недоступна, поэтому ориентироваться стоит именно на сохранённое описание программы, а при выборе обучения полезно отдельно спросить себя: будет ли в программе самостоятельная практика по flaky-сценариям и как вы проверите, что умеете заменять sleep на проверяемые ожидания.