Ждите результата, а не часов

Форма настроек сохраняется медленно. Кто-то добавляет двухсекундную паузу перед проверкой сообщения об успехе. Это передается на их ноутбук. Следующий запуск CI займет немного больше времени и завершится неудачей. Другой разработчик меняет паузу на пять секунд. Тест теперь выполняется медленнее, но причина, по которой он должен продолжаться, по-прежнему отсутствует.

Полезный вопрос не в том, сколько секунд спать. Именно это говорит о том, что следующий шаг готов. В этом руководстве построена небольшая проверка сохраненных настроек вокруг этого вопроса с использованием документации по утверждениям Playwright и ее руководства по передовому опыту. Снимок экрана представляет собой иллюстративную локальную демонстрацию, а не клиентское приложение или тест продукта.

Пауза загадывает. Условие проверяется.

В демо-версии нажатие кнопки "Сохранить" изменяет элемент состояния с "Сохранение" на "Сохранено" после задержки. Запрос немедленной видимости делает снимок настоящего. Он не ждет будущего состояния. Утверждения Web-first Playwright неоднократно проверяют локатор до тех пор, пока не выполнится ожидаемое условие или не истечет их тайм-аут.

Сравните два подхода в тесте, где страница уже перешла к вашей собственной форме промежуточных настроек:

// A fixed delay does not express the requirement.
await page.getByRole('button', { name: 'Save', exact: true }).click();
await page.waitForTimeout(2000);
expect(await page.getByRole('status').innerText()).toBe('Saved');

// The expected state controls when the check finishes.
await page.getByRole('button', { name: 'Save', exact: true }).click();
await expect(page.getByRole('status')).toHaveText('Saved');

Это альтернативные фрагменты, а не инструкции по двойному клику за один тест. Второе утверждение может завершиться, как только появится надпись Saved. Если он никогда не появляется, утверждение терпит неудачу вместо ожидания на неопределенный срок. Тайм-аут утверждения по умолчанию составляет пять секунд в соответствии с текущей документацией по утверждениям; выбирайте локальный тайм-аут только тогда, когда ожидаемое поведение вашего продукта оправдывает это.

Автоматическое ожидание - это не то же самое, что ожидание результата

Playwright проверяет возможность действия перед такими действиями, как щелчок. Кнопка может быть видимой, стабильной, включенной и способной получать события. Это ответ на вопрос, может ли произойти щелчок. Это не доказывает, что запрос на сохранение завершен или что сервер сохранил новые настройки.

Статус успеха может быть разумным условием готовности к следующему шагу пользовательского интерфейса, но он не является независимым доказательством устойчивости. Держите эти задания отдельно: дождитесь "Сохранено", перезагрузите страницу настроек, затем проверьте выбранное значение. В нашей предыдущей статье о независимых результатах обсуждается эта граница доказательства; В этом руководстве основное внимание уделяется механизму синхронизации, который обеспечивает надежную проверку.

await expect(page.getByRole('status')).toHaveText('Saved');
await page.reload();
await expect(page.getByLabel('Display name')).toHaveValue('Demo user');

В примере предполагается наличие доступного поля с именем Отображаемое имя и промежуточной записи с возможностью перезагрузки. Определите эти контракты в демо-версии или в своем приложении. Не меняйте профиль живого пользователя, чтобы было удобно провести эксперимент по выбору времени.

Если ожидание не удалось, не раздувайте его первым

Истекший тайм-аут утверждения является свидетельством для проверки. Статус может никогда не обновиться. Тест может быть нацелен на старый компонент. Сохранение может не состояться. Или продукт может законно занять больше времени, чем текущие ожидания. Прежде чем менять тайм-аут, проверьте действие и полученный пользовательский интерфейс.

[Руководство по действиям] Playwright (https://playwright.dev/docs/actionability) объясняет, какие действия ждут, а какие утверждения повторяются. Общие проверки на равенство не приобретают такого поведения просто потому, что внутри них находится ожидаемое значение. Предпочитайте утверждение локатора для изменения состояния пользовательского интерфейса; используйте ограниченное утверждение опроса, когда условие находится за пределами этой формы.

Не превращайте каждый сбой в больший общий тайм-аут. Более длинный потолок скрывает симптомы и может привести к тому, что прерывистая пробежка может занять гораздо больше времени. Запишите предполагаемый сигнал готовности и кому он принадлежит. Если сигнала нет, более четкое состояние загрузки или тестовый контракт могут быть лучшим решением, чем еще один сон.

Карточка обзора созданных тестов

Для каждого шага, зависящего от времени, запишите действие, состояние готовности, причину тайм-аута и окончательную проверку результата. В нашей демонстрации: Сохранить, статус равен "Сохранено", согласованное окно ответа на сохранение, затем поле сохраняется после перезагрузки. Эту небольшую карточку легче просмотреть, чем кучу пауз.

AnyTest описывает агентов, изучающих веб-приложение и проводящих сквозные тесты для проверки человеком. Если сгенерированный поток кажется слишком быстрым или ненадежным, рецензент должен спросить, что делает каждый переход готовым. Это принцип проверки, а не утверждение, что AnyTest предоставляет настройки Playwright или сгенерированный код в определенном формате.

Один инженер QA получает преимущества, когда правила синхронизации достаточно ясны, чтобы их могли поддерживать разработчики. Команда без выделенного QA может использовать ту же карту во время проверки кода. Цель - тест, который ждет правильной причины, завершается неудачей с полезными границами и никогда не принимает паузу за доказательство.