Помилка HTTP все одно є відповіддю HTTP.
Відділіть невдалий статус від збою транспорту при діагностиці запиту.

Перекладне видання. Технічні ідентифікатори залишаються в оригінальній формі.

Панель не завантажується, тест чекає requestfailed. Нічого: сервер повернув HTTP-помилку. Відсутність події не доводить успіху. Тест питав про неправильну межу.
Посібник використовує мережеву документацію Playwright і Page з локальними запитами: контрольований 503 і навмисний route-abort. Немає клієнтського endpoint чи аварії. Статус і транспорт окремі.
Читайте статус явно
API описує request, response і requestfinished для завершення. HTTP-помилка є відповіддю, не requestfailed. Транспорт закінчився, а обіцянка продукту порушена.
const pending = page.waitForResponse(response =>
response.url().endsWith('/demo-unavailable')
);
await page.getByRole('button', { name: 'Load demo panel' }).click();
const response = await pending;
expect(response.status()).toBe(503);
await expect(page.getByRole('status')).toHaveText('Demo service unavailable');Потрібні кнопка й контрольований сервер. Інтерфейс повідомляє помилку. Очікувати 503 правильно в негативному прикладі, не справжньому успішному сценарії.
Почніть очікування до дії. Оберіть endpoint та ідентичність за контрактом. Широкий обробник може прийняти сторонню відповідь.
Використовуйте requestfailed для його питання
Він описує відсутність нормальної завершеної відповіді, наприклад транспортний збій. Інший приклад використовує route.abort(). Перевіряємо URL та опис, не однаковий текст усіх браузерів.
Переривання не серверний 503. Назви й очікування окремі. Якщо обидва потребують повтору, перевірте відновлення в кожному без змішування причин.
Подія не визначає виробничу причину. Допомагає дослідженню, не встановлює сервер, мережевий перехід чи політику. Зіставте докази в дозволеному середовищі.
Не плутайте транспорт і продукт
Відповідь може мати допустимий статус і неправильний запис чи тіло. Статус - частина контракту. Перевірте вміст та UI без розширення демонстрації.
Сервер рахує завершений 503 без requestfailed. Переривання дає requestfailed. Це семантика, не вимір надійності й не зовнішня аварія.
Не повторюйте кліки через відсутню подію. Сервер уже міг отримати дію; повтор дублює її. Спочатку визначте межу й дозволений повтор.
Зберігайте конкретні терміни
Запишіть endpoint, статус чи подію, UI-результат і невідоме. Це корисніше Мережа зламалася. Захистіть приватні URL та дані до поширення.
AnyTest описує тести для огляду після дослідження. Запитайте про подію й відновлення. Мережева реалізація AnyTest не заявляється. Розрізняйте невдалу відповідь і відсутність завершеної відповіді.
Завершення відповіді не доводить потрібного бізнес-результату. Продукт може вимагати правильний запис, вміст або корисне відновлення. Звіт відділяє перевірене від невідомого. Локальний приклад не встановлює причину зовнішнього інциденту: ізолює дві події з відомими входами. Відсутність успішної функції не тотожна відсутності транспортної відповіді. Якщо продукт пропонує повтор, його дозвіл та безпечний результат перевіряються окремо від самої назви події.
Загальні запитання
Чи HTTP 503 автоматично викликає requestfailed?
Ні. Це відповідь; перевірте статус явно.
Чи requestfinished доводить успіх продукту?
Ні. Транспорт, статус, вміст і результат різні.