Відеобібліотека
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Class name позначає page, methods описують actions, locators зберігаються в одному місці, а open завершується мінімальною readiness check.
Після open() test продовжується лише коли heading Sign in видимий; fill_email() приховує locator details від test code.
Поточний Python contract locator actions, fill(), press_sequentially() та input value APIs.
Для звичайного поля використовується fill(), а результат перевіряється як value, не як text content.
Searchbox має value playwright.
Знайдіть поле, де suggestion list з’являється після окремих keyboard events.
Порівняйте fill() і press_sequentially() на тому самому observable result.
Залиште повільніший API лише якщо test доводить потребу в keyboard events.
Два test runs і висновок, який event contract потребує application.
У відео під час пошуку потрібного API згадуються type і посимвольне введення.
Поточна Python-документація позначає locator.type() як deprecated. Для більшості полів рекомендовано fill(), а для окремих keyboard events — press_sequentially(), доданий у v1.38.
Playwright v1.38 introduced locator.press_sequentially; the current documentation deprecates locator.type.
Як Playwright взаємодіє з браузером через протокол →Playwright Test надає isolated page, а locators виражають user-facing contract через label, role і accessible name.
Test проходить лише проти application, що має наведений login contract.
Що має вміти та знати мідл автоматизатор →[Дивитися з 25:45](https://www.youtube.com/watch?v=6QdvE9DHOIY&t=1545s). `fill()` фокусує поле, замінює значення та генерує input-related event. Це рекомендований і швидкий варіант для звичайних text fields. Посимвольне `pressSequentially()` потрібне лише тоді, коли application реагує на окремі `keydown`/`keypress`/`input`/`keyup`: autocomplete після перших символів, input mask, formatter номера телефону або custom keyboard handler. Практичний сценарій для autocomplete: ввести мінімальну кількість символів, дочекатися suggestion list, вибрати потрібний option і перевірити кінцевий state. Посимвольне введення не повинно ставати глобальним workaround для слабких очікувань, бо воно робить suite повільнішим.
Перед діями Playwright автоматично перевіряє actionability елемента: видимість, стабільність, можливість отримувати події та, залежно від операції, `enabled` або `editable`. Через це для звичайних `click`, `fill`, `hover` чи drag-and-drop не потрібно вручну дублювати очікування, типові для Selenium. Вбудовані Playwright assertions також повторюють перевірку до timeout, тому в них потрібно передавати `Locator`, а не вже отримане статичне значення. Автор називає сторінку документації про auto-waiting ключовою та застерігає від бездумного додавання `waitFor` перед кожною дією.
[Дивитися з 09:10](https://www.youtube.com/watch?v=6QdvE9DHOIY&t=550s). Для `click`, `dblclick`, `fill`, evaluate та інших actions у команду входять target locator, parent frame і options. Browser-side automation layer виконує пошук у правильному контексті та повертає результат або error. На прикладі Chromium автор пояснює роль Chrome DevTools Protocol і показує інструмент командного рядка, який також керує browser через локальний service. Для порівняння Selenium client зазвичай спілкується з browser-specific WebDriver через W3C WebDriver protocol, а driver уже координує browser. В обох випадках test code не клікає DOM напряму: між ним і browser є protocol та процес, що виконує команди.
Функції Page Object називаються за дією тест-кейсу й починаються з дієслова; класи, файли, variables і constants позначають сутності або дані. Для однакових дій команда має обрати один словник — наприклад, послідовно використовувати `fill`, `click` і `select`, бажано близько до API обраного framework. Функцію, яка натискає кнопку, не варто називати `openPage`: окрема navigation-функція може відкривати URL напряму, обходячи довгий UI-шлях. Неминучі суперечки на code review краще завершити коротким naming convention у README, а не щоразу вирішувати те саме заново.