Чекайте на результат, а не на годинник

Форма налаштувань зберігається повільно. Хтось додає двосекундну паузу перед перевіркою повідомлення про успіх. Це передається на їхній ноутбук. Наступний запуск CI займає трохи більше часу та не вдається. Інший розробник змінює паузу на п'ять секунд. Тест тепер повільніший, але причина його продовження все ще відсутня.

Корисне питання полягає не в тому, скільки секунд потрібно спати. Це докази того, що наступний крок готовий. У цьому посібнику створено невелику перевірку збережених налаштувань щодо цього питання, використовуючи документацію про твердження Playwright і посібник із найкращих практик. Знімок екрана є ілюстративною локальною демонстрацією, а не клієнтською програмою чи тестом продукту.

Пауза вгадує. Умова перевірки.

У демо-версії натискання "Зберегти" змінює статус елемента зі "Збереження" на "Збережено" після певної затримки. Миттєвий запит видимості робить моментальний знімок сьогодення. Воно не чекає майбутнього стану. Твердження Playwright web-first неодноразово перевіряють локатор, доки очікувана умова не виконається або не закінчиться час очікування.

Порівняйте два підходи в тесті, де сторінка вже перейшла до вашої власної форми налаштувань проміжки:

// 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');

Це альтернативні фрагменти, а не вказівки клацати двічі в одному тесті. Друге твердження можна завершити, як тільки з'явиться Збережено. Якщо він ніколи не з'являється, твердження не виконується, а не чекає нескінченно довго. Тайм-аут твердження за замовчуванням становить п'ять секунд відповідно до поточної документації твердження; вибирайте локальний тайм-аут лише тоді, коли це виправдовує очікувана поведінка вашого продукту.

Автоматичне очікування не те саме, що очікування результату

Playwright перевіряє дієвість перед такими діями, як клацання. Кнопка може бути видимою, стабільною, увімкненою та здатною отримувати події. Це визначає, чи може відбутися клацання. Це не доводить, що запит на збереження завершено або що сервер зберіг нові налаштування.

Статус успіху може бути розумною умовою готовності до наступного кроку інтерфейсу користувача, але він не є незалежним доказом стійкості. Зберігайте ці завдання окремо: зачекайте на "Збережено", перезавантажте сторінку налаштувань, а потім перевірте вибране значення. У нашій попередній статті про незалежні результати обговорюється ця межа доказу; цей посібник зосереджується на механізмі синхронізації, який забезпечує надійний доступ до перевірки.

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

У прикладі передбачається доступне поле під назвою "Відображуване ім'я" та проміжний запис, безпечний для перезавантаження. Визначте ці контракти в демонстраційній версії або у своїй програмі. Не змінюйте профіль живого користувача, щоб зробити експеримент із визначенням часу зручним.

Коли очікування не вдається, не накачуйте його спочатку

Закінчився тайм-аут твердження є доказом для перевірки. Статус може ніколи не оновлюватися. Тест може бути націлений на старий компонент. Збереження може не вдатися. Або продукт може законно зайняти більше часу, ніж поточне очікування. Перш ніж змінювати час очікування, перевірте дію та кінцевий інтерфейс користувача.

У посібнику щодо дій Playwright пояснюється, які дії чекають, а які твердження повторюються. Загальні перевірки рівності не набувають такої поведінки просто тому, що в них знаходиться очікуване значення. Віддавати перевагу твердженням локатора для зміни умов інтерфейсу користувача; використовувати обмежене твердження опитування, коли умова знаходиться поза цією формою.

Уникайте перетворення кожної помилки на більший спільний тайм-аут. Довша стеля приховує симптоми і може призвести до того, що перерваний пробіг триватиме набагато довше. Запишіть передбачуваний сигнал готовності та кому він належить. Якщо сигналу немає, більш чіткий стан завантаження або тестовий контракт може бути кращим виправленням, ніж інший сон.

Картка перегляду згенерованих тестів

Для кожного кроку, залежного від часу, запишіть дію, стан готовності, причину тайм-ауту та остаточну перевірку результату. У нашій демонстрації: "Зберегти", статус дорівнює "Збережено", узгоджене вікно відповіді на збереження, потім поле зберігається після перезавантаження. Цю маленьку картку легше переглянути, ніж купу пауз.

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

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