← Java

Після цього уроку ви зможете

Конспект і таймкоди

0:00

Гіпотеза про бізнес-важливі елементи

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

Основний trade-off — не додати в кожен перехід зайві очікування. Які саме сигнали належать до isLoaded, залежить від типу сторінки та наступної дії тесту.

1:10

Спочатку стабільність, потім оптимізація

Початковий end-to-end тест має бути стабільним. Лише після цього його можна декомпозувати або переносити частину перевірок на нижчі рівні заради швидкості.

isLoaded підтримує стабільність двома способами: фіксує видимий користувацький стан і рано зупиняє сценарій із зрозумілою помилкою, якщо сторінка не готова.

Уточнення

Не дублюй auto-waiting у isLoaded

Playwright уже чекає actionability для конкретної action. isLoaded має додавати лише business readiness, якої одна action не доводить: завершене завантаження списку, зникнення blocking loader або поява повного payment form.

Термін

actionability

Набір перевірок Playwright перед дією. Для click це, зокрема, unique match, visible, stable, receives events та enabled.

2:20

Динамічний контент і blocking loader

У динамічному UI HTML може вже існувати, але продукти, кошик або кнопка checkout ще не готові. Тест, який одразу клікає елемент, отримує flaky failure: дія сталася раніше, ніж сторінка могла її обробити.

Надійний readiness contract чекає, що blocking preloader зник, skeleton замінився реальним контентом, а ключовий елемент став видимим або доступним для дії.

Що змінилося після запису

load event не дорівнює business readiness

АктуальноПоточна документація Playwright прямо застерігає, що універсального стану «page loaded» немає: після browser load application може ще отримувати дані або завершувати hydration. Якщо видимий control не реагує, спочатку перевір hydration; product-side виправлення — тримати control disabled до готовності, а не додавати sleep у тест.

Термін

Locator

Повторно обчислюваний опис пошуку елемента; Playwright знаходить актуальний DOM element перед кожною дією й поєднує Locator з auto-waiting.

Практика

Діагностувати hydration під Slow 3G

  1. Увімкни Slow 3G у DevTools, одразу взаємодій із видимим control і перевір, чи handler уже підключений. Якщо дія губиться, зафіксуй product-side умову готовності без sleep у тесті.
  • Проблему відтворено або виключено на сповільненій мережі.
  • Відокремлено browser load, видимість control і завершення hydration.
  • Запропоновано disabled state до готовності, якщо handler підключається пізніше.
3:09

Готовність складених і iframe-елементів

Payment page часто збирається кількома асинхронними етапами: зникає загальний loader, з’являється billing address, потім завантажуються поля платіжного iframe. Формальна поява контейнера ще не означає, що користувач може вводити дані.

Тому isLoaded повинен чекати саме готових полів або іншого мінімального набору елементів, потрібних наступному кроку сценарію.

Термін

FrameLocator

Locator boundary для елементів усередині iframe; дозволяє далі використовувати role, label та інші locator strategies в потрібному frame.

4:12

Перевіряємо готовність, а не ідеальність анімації

Не потрібно перевіряти кожен кадр анімації. Достатньо спостережуваного переходу: loader зник, skeleton замінився карткою, назва продукту видима, критична дія доступна.

Уповільнення мережі в DevTools допомагає знайти реальні проміжні стани й вибрати правильний сигнал. Підсумкове правило: isLoaded описує те, що користувач очікує побачити перед продовженням роботи, і те, без чого тест не може виконувати наступну дію стабільно.

Термін

web-first assertion

Assertion, який автоматично повторює перевірку до очікуваного стану або timeout, наприклад to_be_visible чи to_be_enabled.

Приклад коду

Мінімальна бізнес-готовність checkout

from playwright.sync_api import Page, expect


def expect_checkout_ready(page: Page) -> None:
    expect(page.get_by_test_id("checkout-loader")).to_be_hidden()
    expect(page.get_by_role("heading", name="Checkout")).to_be_visible()
    expect(page.frame_locator("#payment-frame").get_by_label("Card number")).to_be_visible()

Перевірка фіксує лише сигнали, без яких користувач не може перейти до payment action; вона не перевіряє кожен animation frame або весь DOM.

Очікуваний результат: Функція завершується лише після готовності ключових checkout controls.

Потрібно: playwright

Практика

Сформулювати readiness contract

  1. Для сторінки зі skeleton, product list і payment iframe вибери мінімальні сигнали, після яких користувач може виконати наступну бізнес-дію.
  • Кожен signal пов’язаний із реальною наступною дією.
  • Немає sleeps або перевірки кожного DOM element.
  • iframe control шукається через frame-aware locator.

Джерела та додаткові матеріали

  • Auto-waiting | Playwright Python ↗Playwright · перевірено 2026-07-31

    Показує, що Playwright уже перевіряє технічну готовність element перед action.

  • Navigations | Playwright Python ↗Playwright · перевірено 2026-07-31

    Пояснює, чому browser load event не дорівнює готовності application і як діагностувати hydration failure.

  • Locators | Playwright Python ↗Playwright · перевірено 2026-07-31

    Пояснює актуальні locators і пошук control усередині iframe.