Відеобібліотека
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Вибрати одну важливу дію в UI.
Написати user-facing locator, test id locator і короткий CSS fallback.
Змінити translation та experiment variant.
Обрати найстабільніший locator і зафіксувати його contract.
Обраний locator залишається однозначним у контрольованих variants, а причина вибору описана одним абзацом.
Locator boundary для елементів усередині iframe; дозволяє далі використовувати role, label та інші locator strategies в потрібному frame.
Що має описувати isLoaded →Візьміть залежний UI test і відокремте browser state від server-side test data.
Замініть випадковий CSS/XPath на user-facing locator там, де є semantic contract.
Запустіть test без retry, зафіксуйте root cause і лише потім порівняйте report із retry enabled.
Незалежний test, locator rationale і report, де retry не приховує root cause.
Повторно обчислюваний опис пошуку елемента; Playwright знаходить актуальний DOM element перед кожною дією й поєднує Locator з auto-waiting.
Що має описувати isLoaded →Поточний Python contract locator actions, fill(), press_sequentially() та input value APIs.
Locator описує кнопку так, як її знаходить користувач через accessibility semantics.
Playwright знаходить одну кнопку Submit і натискає її.
Пріоритети селекторів та їхня надійність →[Дивитися з 00:00](https://www.youtube.com/watch?v=6QdvE9DHOIY&t=0s). Playwright складається з багатьох частин: browser lifecycle, locators, actions, assertions, downloads, reporting і tracing. Щоб відповісти на питання «що відбувається під капотом», автор відкриває реалізацію `Locator`, а не обмежується документацією верхнього рівня. `Locator` зберігає frame і спосіб пошуку елемента, а додаткові умови на кшталт `has`, `hasText` чи visibility-related filters добудовують запит. У Python named arguments роблять таку композицію схожою на Builder без окремого builder class. Практичний висновок: перед створенням власного selector DSL варто перевірити вже наявні аргументи конструктора й методи locator API.
Для assertions слід використовувати API, що повертає `Locator`: `locator(...)`, `getByRole(...)`, `getByText(...)` та споріднені методи. У документації Playwright пріоритет надається user-facing locator-ам, але відео рекомендує не перетворювати це на механічне правило й підбирати locator за реальним DOM та потребами команди. Playwright розширює CSS-пошук перевірками тексту, видимості й відносного розташування, однак надто складні конструкції та XPath ускладнюють підтримку. Якщо стабільного сигналу немає, краще домовитися з розробниками про data attribute; `getByTestId` фактично є зручною обгорткою над таким контрактом.
У перенесеному тесті навігація виконується через `page.navigate`, пошук — через `page.locator`, а перевірка — через Playwright assertions. Тест запускається у браузері й успішно проходить після коригування локатора. Playwright locator може описувати кілька DOM-вузлів, але операція, що очікує один елемент, завершується помилкою strict mode. На відміну від Selenium `findElement`, який із множини повертає перший збіг, у Playwright потрібно зробити locator унікальним або явно вибрати `first`; правило стосується і дій, і assertions.
Playwright пропонує `getByRole`, `getByLabel`, `getByText`, `getByPlaceholder` та інші user-facing locator-и. `getByRole` спирається на accessibility semantics і допомагає перевіряти, чи інтерфейс коректно описує кнопки, поля та таблиці для screen reader; особливо зручним такий пошук може бути для рядків і колонок таблиці. Автор водночас застерігає, що role-based locator-и іноді складніше читати й діагностувати команді. Для більшості проєктів він радить обирати найпростіший стабільний CSS selector або узгоджений data attribute, а accessibility locator використовувати там, де він справді дає читабельний і надійний контракт. API портів Playwright загалом однаковий у Java, Python, C# і TypeScript. Практична перевага TypeScript-версії в тому, що власний Playwright Test runner автоматично надає готовий `Page`; у Java lifecycle потрібно організувати через JUnit або власну обгортку.
Замість довгого `locator.waitFor` для очікуваного стану використовується динамічний Playwright assertion на `Locator`, наприклад перевірка видимості або тексту. Так очікування і причина падіння залишаються частиною перевірки, а не окремим технічним кроком. Для `HomePage`, `SignInPage`, `ProjectsPage` і сторінки окремого проєкту створюються Page Object-и. Кожен отримує спільний `Page` через constructor, зберігає дії на своїй сторінці та повертає наступний Page Object там, де сценарій переходить далі. Початковий лінійний тест рефакториться у послідовність доменних дій: відкрити home page, увійти, знайти проєкт, відкрити його й перевірити title. Це прибирає locator-и з тесту та залишає у ньому читабельний користувацький сценарій.
`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-обгортка пов'язана з командами, які фактично виконує браузер.
Playwright рекомендується як швидша й зручніша основа для UI automation, особливо на remote execution. У Java повторювану ініціалізацію можна прибрати через JUnit integration, Page Object-и та невелику application facade, а стабільність дій забезпечують auto-waiting і динамічні assertions. Для домашньої роботи потрібно переписати на Playwright наявний Selenium-сценарій, налаштувати browser options, увімкнути tracing, відкрити trace локально та використати `page.pause()` або recorder для налагодження. Згенеровані recorder-ом кроки слід переносити вибірково й узгоджувати locator strategy в межах команди. `getByRole` додатково перевіряє accessibility semantics сторінки: сучасні Angular і React components мають формувати ролі та ARIA attributes, які screen reader розпізнає як кнопку, поле введення чи інший control. Для колекцій strict locator semantics складніша, тому в більшості дій варто будувати locator, що знаходить один конкретний елемент.
`getByRole` спирається на роль і accessible name з accessibility tree. Інші user-facing locators — `getByLabel`, `getByText`, `getByPlaceholder`, `getByAltText` і `getByTitle` — шукають за відповідним видимим або описовим значенням. Усі вони читаються ближче до наміру користувача й роблять failure зрозумілішим для розробників — основної аудиторії результатів автотестів. Незначна різниця в швидкості locator неважлива порівняно з network та application latency.
Варто розуміти порядок, у якому test runner завантажує модулі, створює suite/test fixtures, запускає setup, test і teardown. Declaration задає ім'я та тип, assignment присвоює значення, а runtime initialization створює фактичний стан під час виконання програми. Точні терміни залежать від мови, але практичне питання однакове: коли ресурс уже існує й хто ним володіє. На співбесіді можуть попросити пояснити різницю між class та object, відрефакторити тест або написати надійний locator. Потрібно знати CSS/XPath настільки, щоб читати старий код, і віддавати перевагу user-facing locator API Playwright, коли семантична роль або label точніше виражає контракт.
[Дивитися з 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.