Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
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.
Демонструє narrowing до desktop container, user-facing locators і explicit assertion; URL та labels є навчальними placeholders.
Test знаходить лише desktop form і перевіряє повідомлення про невалідний login.
3. Селектори та пошук елементів →Для звичайного поля використовується 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 взаємодіє з браузером через протокол →Поля заповнюються через `locator(...).fill(...)`, а кнопка може шукатися за роллю та доступним ім’ям. Приклад структури сценарію: ```python page.locator("#content-desktop #user_email").fill("user@example.com") page.locator("#content-desktop #user_password").fill("invalid-password") page.get_by_role("button", name="Sign in").click() ``` Для швидкої роботи з кодом автор налаштовує розширення й звуження виділення (`Extend Selection`, `Shrink Selection`) та перехід між словами через `Option+Left/Right`. Гарячі клавіші мають прискорювати точні дії, а не приховувати нерозуміння поточного контексту.
[Дивитися з 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 підтримує тривалий двосторонній канал із browser process і через browser-specific protocol передає команди click, fill, navigation та читання стану. Locator actions мають auto-waiting: перед дією Playwright перевіряє релевантні actionability conditions — наприклад, видимість, стабільність, можливість отримати events і editable state. Це дозволяє тесту формулювати намір «виконай click для цього locator», а orchestration layer бере на себе очікування готовності елемента в межах timeout. Auto-waiting не усуває потребу в assertion: після дії все одно треба перевірити очікуваний результат. Основні browser engines Playwright — Chromium, Firefox і WebKit. WebKit наближає поведінку Safari, але не є повною копією всіх Safari/macOS/iOS інтеграцій. Branded Chrome або Edge можуть запускатися як Chromium channels, проте повну browser matrix потрібно визначати з реальної product analytics і support policy.
Інший recorder записує кроки login-сценарію та дозволяє обрати мову експорту. Згенерований приклад містить `goto`, `fill` і `click`, але не враховує дубльовані `#content-mobile` та `#content-desktop` блоки на сторінці Testomat.io. Через це локатор поля може знайти кілька вузлів і впасти у strict mode. Генератор бачить окрему дію, але не обов’язково розуміє контекст DOM або усталену архітектуру тестів. Код є чернеткою, а не готовим тестом.
У `BasePage` демонструються helpers для `open`, `refresh`, `find`, `find_all`, `click` і введення тексту. Перед дією helper чекає потрібний стан: visibility для введення або clickability для кліку. Так exception вказує на невиконану передумову, а не на випадковий наступний Selenium command. `send_keys()` вводить символи та може передавати спеціальні клавіші на кшталт Enter або Tab. На відміну від високорівневого fill у Playwright, він не гарантує очищення поля, тому `clear()` додається лише там, де сценарій справді починає з порожнього input. Не варто приховувати `clear()` у кожному введенні «про запас». Тест має явно задавати стартовий стан: іноді потрібен refresh, бо попередня невдала авторизація залишила validation message або інший стан, який просте очищення полів не скидає.
[Дивитися з 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, а не щоразу вирішувати те саме заново.