web-first assertion
Assertion, який автоматично повторює перевірку до очікуваного стану або timeout, наприклад to_be_visible чи to_be_enabled.
Що має описувати isLoaded →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Терміни, нюанси та джерела
Timeout, navigation і стабільність елемента
[Дивитися з 20:00](https://www.youtube.com/watch?v=6QdvE9DHOIY&t=1200s). Timeout можна задавати для конкретної operation або централізовано на рівні page/context. Локальні довільні timeout-и у кожному locator виклику ускладнюють поведінку suite, тому корисніше мати послідовну default policy й змінювати її лише для підтверджених винятків. У відео розбираються load states `domcontentloaded`, `load` і `networkidle`, а також події detach, close та navigation timeout. `networkidle` не є універсальним доказом готовності application: сучасна сторінка може мати постійний network traffic. Надійніша перевірка — очікування конкретного observable UI state через locator або web-first assertion. Стабільний element означає, що його bounding box не змінюється протягом послідовних animation frames. Це захищає від кліку в element, який ще рухається або змінює розмір під час layout/animation.
`WebDriverWait`, `FluentWait` і polling interval
Окремий клас waits створює `WebDriverWait` для поточного драйвера з timeout 10 секунд. `pollingEvery(Duration.ofMillis(100))` означає, що до завершення timeout умова перевірятиметься приблизно кожні 100 мс. `WebDriverWait` наслідує `FluentWait`, тому обидва мають спільну основу: timeout, polling і можливість ігнорувати визначені exceptions. Різниця в API не заважає передати до `until` власну lambda або `ExpectedCondition`, яка перевіряє кілька властивостей за один виклик.
Межі низькорівневого API й options окремих дій
Playwright має API для keyboard shortcuts через `page.keyboard().press(...)`, WebSocket events і mocking. Водночас автору бракує ланцюжків на кшталт «динамічно дочекайся тексту, а потім клікни цей самий елемент», тому у власній бібліотеці він додає коротші chainable operations. Окремі actions та assertions приймають options objects. Для конкретної перевірки можна змінити timeout; `FillOptions` і подібні об'єкти дозволяють задати власний timeout або `force`. `force` обходить частину actionability checks і потрібен лише як виняток для проблемного frontend, а не як стандартний спосіб виправляти тести.
`CollectionCondition` і timeout перевірок
Колекцію можна перевіряти через `shouldHave(...)` та умови з `CollectionCondition`. У демонстрації розглядаються перевірки розміру, `sizeGreaterThan(...)` і точних текстів. Перевірка списку текстів також звіряє кількість елементів, тому падає, якщо очікуваних значень менше, ніж реально знайдених. Падіння прикладу показує стандартне очікування близько чотирьох секунд. Глобальний `Configuration.timeout` можна змінити, після чого непараметризовані `should...` чекатимуть новий час. Збільшувати його варто свідомо: це впливає на всі відповідні перевірки, а не лише на один повільний елемент.
Діагностика waits і власні `ExpectedCondition`
`WebDriverWait` можна доповнити власним timeout message і переліком exceptions, які ігноруються під час polling. Як приклад розглядається `StaleElementReferenceException`: якщо DOM оновився між двома перевірками, wait може повторити умову замість негайного падіння. Ігнорувати всі exceptions без розбору не радять — перелік має відповідати очікуваним перехідним станам. Власна умова може через lambda знайти елемент і послідовно перевірити `isDisplayed()`, `isEnabled()` та текст. Її текстове представлення або окремий message потрапить до timeout diagnostics. Для складної перевірки це дає контроль над поведінкою, але готові `ExpectedConditions` варто перевикористовувати, доки вони виражають потрібний контракт.
Auto-waiting і динамічні assertions
Перед діями Playwright автоматично перевіряє actionability елемента: видимість, стабільність, можливість отримувати події та, залежно від операції, `enabled` або `editable`. Через це для звичайних `click`, `fill`, `hover` чи drag-and-drop не потрібно вручну дублювати очікування, типові для Selenium. Вбудовані Playwright assertions також повторюють перевірку до timeout, тому в них потрібно передавати `Locator`, а не вже отримане статичне значення. Автор називає сторінку документації про auto-waiting ключовою та застерігає від бездумного додавання `waitFor` перед кожною дією.
`WebElement` проти `By` усередині очікування
Перший запуск падає з `NoSuchElementException`, хоча елемент згодом з'являється на сторінці. Причина — `findElement` виконується ще до входу в `wait.until(...)`: Selenium спочатку намагається передати готовий `WebElement`, і очікування не отримує можливості повторювати пошук. Коли в `ExpectedConditions` передається `By`, локатор залишається всередині циклу очікування. Тоді `WebDriverWait` протягом заданого timeout повторно перевіряє, чи знайдений елемент і чи містить він потрібний текст. Для динамічної сторінки варіанти на кшталт `visibilityOfElementLocated(By)` і `textToBePresentInElementLocated(By, text)` гнучкіші за умови, які приймають уже знайдений `WebElement`.
Actionability і правильна область кліку
[Дивитися з 14:20](https://www.youtube.com/watch?v=6QdvE9DHOIY&t=860s). Перед дією Playwright перевіряє її передумови. Для `locator.click()` це, зокрема, strict resolution до одного елемента, visibility, stability, здатність отримувати pointer events і enabled state. Якщо умови не виконуються до завершення timeout, action завершується помилкою замість випадкового кліку. Візуальний текст усередині button не завжди є правильним click target: event listener може бути на батьківському element, а вкладений `span` — лише оформленням. Через це семантичний locator на кшталт `getByRole('button', { name: ... })` часто стабільніший за пошук найглибшого text node. Велика активна область також краща для користувача й доступності. Вибір між `click()` і touch-oriented `tap()` має залежати від реального input mode та context configuration, а не лише від розміру viewport.
Debugger, recorder і внутрішній transport
`page.pause()` зупиняє виконання й відкриває Playwright Inspector. У ньому можна покроково продовжувати тест, бачити підсвічений цільовий елемент, записувати дії та отримувати згенерований код для Java/JUnit або інших підтримуваних мов. Pick locator допомагає знайти елемент і пропонує locator на основі placeholder, role, label чи іншого доступного сигналу. Результат recorder-а є стартовою точкою: згенерований locator потрібно перевірити на унікальність, читабельність і стабільність перед перенесенням у Page Object. Під час переходу в реалізацію Java API показано, що Playwright формує protocol message, передає його transport-ом через WebSocket, отримує результат і перетворює помилку або timeout на Playwright exception. Це пояснює, як Java-обгортка пов'язана з командами, які фактично виконує браузер.