Як Playwright взаємодіє з браузером через протокол

[Дивитися з 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.

[Дивитися з 04:40](https://www.youtube.com/watch?v=6QdvE9DHOIY&t=280s). Перехід у реалізацію click() показує виклик на кшталт channel.send(...): назва команди та її parameters передаються нижчому шару. Далі досліджується ієрархія об’єктів: Browser створює BrowserContext, context містить Page, а page працює з frames і locators.

Python- і Java-клієнти не реалізують browser automation незалежно від основного Playwright driver. Вони формують команди та обмінюються повідомленнями з driver process через transport. Саме тому package містить platform-specific executable, а public API різних мов лишається концептуально подібним.

[Дивитися з 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 та процес, що виконує команди.

[Дивитися з 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.

[Дивитися з 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.

[Дивитися з 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 повільнішим.

from playwright.sync_api import Page, expect

def test_search_value(page: Page) -> None:
    search = page.get_by_role("searchbox")
    search.fill("playwright")
    expect(search).to_have_value("playwright")

[Дивитися з 30:00](https://www.youtube.com/watch?v=6QdvE9DHOIY&t=1800s). Текст, який користувач бачить усередині input, зберігається як value, а не як дочірній text node. Тому textContent() або toHaveText() може повернути порожнє значення навіть тоді, коли поле візуально заповнене.

Для form control треба використовувати inputValue() або assertion toHaveValue(). Pattern/regular expression дозволяє перевірити форматоване значення без ручної конкатенації. Така перевірка особливо важлива після autocomplete або mask, де DOM value може відрізнятися від рядка, надісланого тестом.

[Дивитися з 34:20](https://www.youtube.com/watch?v=6QdvE9DHOIY&t=2060s). Автор порівнює Playwright із Selenium CDP/BiDi APIs і досліджує documentation та source code наживо. Показано ризик version coupling: browser protocol modules, Selenium version і browser/driver version мають бути сумісними, інакше потрібна feature може бути недоступною.

Network interception, request mocking і browser events у різних поколіннях Selenium APIs мали різний рівень готовності та різні способи підключення. Цей фрагмент варто сприймати як метод дослідження, а не стабільну шпаргалку API: перед реалізацією треба перевірити документацію саме встановленої версії dependency.

[Дивитися з 40:00](https://www.youtube.com/watch?v=6QdvE9DHOIY&t=2400s). Кілька переходів у implementation показують ланцюг від Locator.click() до frame/channel command. Client збирає action options і надсилає повідомлення через connection; browser-side layer виконує пошук, actionability checks і дію.

Під час дослідження автор спочатку припускає, що assertions повністю виконуються в Python client, а потім знаходить protocol command для locator expect. Практичний урок тут важливіший за конкретний internal class: перевіряти припущення переходом у реалізацію, trace або protocol logs і явно коригувати висновок, коли source code показує інше.

[Дивитися з 44:20](https://www.youtube.com/watch?v=6QdvE9DHOIY&t=2660s). Підсумкова ієрархія: створюється root Playwright instance, далі Browser, BrowserContext і Page; locators працюють у frame/page context. ChannelOwner та connection/transport пов’язують language client із driver process, а browser executable і потрібні artifacts перевіряються під час installation та startup.

Для співбесіди достатньо пояснити модель без переказу кожного internal class: locator описує target; action збирає parameters; client надсилає command через transport; browser-side implementation виконує потрібні checks та повертає result; Playwright додає auto-waiting, locators, assertions, traces і reporting. Деталі protocol залежать від browser engine і версії Playwright.