Как дождаться результата фоновой задачи через expect.poll в Playwright

expect.poll повторяет вызов проверяющей функции, пока её результат не удовлетворит ожиданию или не закончится тайм-аут. На Mentoring.digital разберём ожидание фоновой операции через API. Сам запуск операции должен происходить один раз, перед опросом.

Определяем контракт учебного API

В примере предполагается API вашего тестового приложения: POST /api/jobs возвращает статус 202 и объект со строковым id. Запрос GET /api/jobs/{id} возвращает состояние задачи. Успешным конечным состоянием считаем "done". Эти пути и значения нужно адаптировать к реальному контракту приложения.

Для относительных URL у тестов должен быть настроен use.baseURL, например адрес локального тестового сервера. Пример не предполагает обращений к рабочему сервису.

Повторяем только чтение статуса

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

test("export finishes", async ({ request }) => {
  const created = await request.post("/api/jobs", {
    data: { kind: "export" },
  });
  expect(created.status()).toBe(202);

  const { id } = await created.json();
  expect(typeof id).toBe("string");

  await expect.poll(async () => {
    const response = await request.get(
      `/api/jobs/${encodeURIComponent(id)}`
    );
    if (!response.ok()) {
      return `http_${response.status()}`;
    }
    const job = await response.json();
    return job.status;
  }, {
    message: "export should finish",
    timeout: 10_000,
    intervals: [100, 250, 500],
  }).toBe("done");
});

Создание вынесено за пределы функции опроса. Повторяются только запросы состояния уже известного ID. Иначе каждая попытка проверки могла бы запускать новую операцию.

При неуспешном HTTP-ответе пример возвращает диагностическую строку. Она не совпадает с "done", поэтому успешная проверка не будет засчитана по одному факту получения ответа.

Задаём предел ожидания осознанно

timeout ограничивает ожидание expect.poll, а intervals задаёт паузы между попытками. В примере использованы учебные значения. Общий тайм-аут самого теста тоже должен позволять выполнить подготовку и проверку.

Состояние "failed" также не удовлетворяет ожиданию "done". В реальном тесте полезно включать идентификатор и последнее состояние в диагностику. Увеличение тайм-аута не исправляет ошибку процесса.

Выбираем проверку по наблюдаемому результату

Если проверяется текст элемента страницы, начните со штатного повторяемого ожидания toHaveText. Опрос функции нужен для результата, который вы получаете самостоятельно, например из API. Для практики предусмотрите успешное завершение, зависшую задачу и ошибочный HTTP-ответ.

Такие сценарии можно отрабатывать на курсах тестирования и QA. Устойчивую проверку асинхронного процесса обсудите с наставником по QA.