Нестабильные тесты Playwright: автоожидание и повторяемые проверки

Определите успех до выбора ожидания

Здесь успех означает текст Saved в статусе после нажатия Save. Само успешное нажатие этого не доказывает. Фиксированная пауза лишь угадывает время операции: короткая ломает медленные запуски, длинная задерживает каждый запуск. Сначала запишите падающее действие, фактический статус и ожидаемый статус.

Данные разных тестов должны быть независимыми. Если соседний тест меняет тот же аккаунт или черновик, ожидание не восстановит нужное исходное состояние. Предпочитайте локаторы по роли и доступному имени. При нескольких совпадениях определите нужный элемент, а не выбирайте случайный первый результат.

• Playwright: test isolation and resilient locators

Выбирайте ожидание под конкретную цель

В таблице разделены действие, ожидаемое изменение интерфейса и произвольное условие. Уже прочитанная строка — снимок текущего значения. Её сравнение не обновляет данные из браузера. Если интерфейс ещё может измениться, передавайте локатор в повторяемую проверку.

• Playwright: retrying and non-retrying assertions

Запустите пример с двумя независимыми задержками

Сохраните код как spec-файл в существующем проекте Playwright Test. HTML имитирует готовность через 300 миллисекунд и завершение через 400 миллисекунд после нажатия. Таймеры находятся в модели приложения; тест не содержит угаданной паузы. Ожидаемый результат: нажатие после включения кнопки, завершение проверки при появлении Saved.

Замените последнюю строку на expect(await page.getByRole('status').textContent()).toBe('Saved'). Проверка может прочитать Draft и упасть, а достаточно медленное чтение способно скрыть гонку. Верните проверку локатора, меняйте обе задержки в пределах настроенного таймаута и повторите запуск. Упражнение показывает разницу между ожиданием чтения и ожиданием нужного состояния.

import { test, expect } from '@playwright/test';

test('save waits for readiness and completion', async ({ page }) => {
  await page.setContent(`
    <button disabled>Save</button>
    <p role="status">Draft</p>
    <script>
      const button = document.querySelector('button');
      setTimeout(() => { button.disabled = false; }, 300);
      button.addEventListener('click', () => {
        setTimeout(() => {
          document.querySelector('[role="status"]').textContent = 'Saved';
        }, 400);
      });
    </script>
  `);

  await page.getByRole('button', { name: 'Save', exact: true }).click();
  await expect(page.getByRole('status')).toHaveText('Saved');
});

• Playwright: retrying and non-retrying assertions

Понимайте границы автоожидания

Для click Playwright проверяет единственный элемент, видимость, стабильность, получение событий указателя и доступность. У разных действий набор проверок отличается. Они подтверждают возможность действия, а не завершение сохранения. При незавершённой гидратации доступная кнопка может ещё не иметь работающего обработчика: отражайте настоящую готовность в приложении, поскольку проверки click не распознают такой разрыв.

Принудительное нажатие может обойти нужные проверки, не исправив состояние. Если Save неожиданно закрыт оверлеем, выясните причину. Дождитесь предусмотренного состояния или исправьте поведение продукта, если оверлея быть не должно.

• Playwright: auto-waiting and actionability checks
• Playwright: test isolation and resilient locators

Выберите исправление по trace падающего запуска

Изучите журнал действий, снимки DOM и сетевые события вокруг сбоя. Локатор нашёл другой элемент, статус не появился или запрос завершился ошибкой? Увеличение таймаута оправдано, если правильному условию действительно требуется больший бюджет. Неверное ожидание оно не исправляет.

Повторные попытки помогают увидеть нестабильность, но успешный повтор всё равно требует исследования. Сохраните trace первого сбоя и исходные данные. Если результат зависит от предыдущего теста, проверьте повторное использование фикстур и общее состояние.

• Playwright: Trace Viewer
• Playwright: test retries

Упражнение на отладку за 15 минут

Начните с немедленного сравнения текста. Объясните гонку, исправьте проверку, затем добавьте вторую кнопку Save. Устраните неоднозначность через подходящий контейнер или различное доступное имя, а не first(). Наконец, запретите приложению публиковать Saved и убедитесь, что исправленный тест падает с понятным таймаутом условия. Всегда проходящий тест ещё не означает исправленный тест.

В связанном обзоре повторите локаторы и изоляцию, затем проговорите объяснение: что наблюдалось, какое предположение нарушилось и что доказывает новая проверка.

• RecallDeck: вопросы по Selenium и Playwright

Коротко

Частые вопросы