CDPSession
Низькорівневий канал Playwright для надсилання raw Chrome DevTools Protocol methods; доступний лише для Chromium-based browsers.
Як Playwright взаємодіє з браузером через протокол →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
W3C WebDriver BiDi
Поточний двосторонній protocol contract і статус Working Draft.
3. Selenium vs Playwright - яка різниця → Першоджерело ↗WebDriver BiDi
W3C protocol для двосторонніх commands та events через WebSocket connection. Специфікація визначає modules для browsing context, input, log, network і script, але станом на 2026-07-31 має статус Working Draft.
3. Selenium vs Playwright - яка різниця →WebDriver remote end
Сторона W3C WebDriver protocol, яка приймає HTTP command від local end, виконує browser automation operation і повертає HTTP response.
3. Selenium vs Playwright - яка різниця →Що змінилося після запису
У підсумку відео звучить широке формулювання, що Playwright працює через DevTools protocol.
Raw CDPSession у public API підтримується лише для Chromium-based browsers; це формулювання не можна узагальнювати на Firefox і WebKit.
Дії, browser protocol і порівняння з WebDriver
[Дивитися з 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 та процес, що виконує команди.
Як команда й assertion доходять до browser
[Дивитися з 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 показує інше.
Як Playwright керує браузером
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.
Selenium WebDriver, explicit waits і ширша matrix
Selenium 4 використовує стандартизований W3C WebDriver protocol. Client binding надсилає HTTP-команди WebDriver endpoint, а browser-specific driver виконує їх у Chrome, Firefox, Edge, Safari чи іншому підтримуваному браузері. У старішому Selenium 3 застосовувався JSON Wire Protocol. У класичному Selenium flow перед click або input часто використовується explicit wait: client повторно перевіряє умову на кшталт visibility або clickability, а після її виконання надсилає окрему action command. Це створює більше round trips, особливо коли browser session віддалена. Сильна сторона Selenium — широка екосистема vendor drivers і remote providers. Якщо навіть невелика частка користувачів певного браузера означає сотні тисяч людей або браузер входить у договірну support matrix, таке покриття не можна відкидати лише через повільніший test run. У Python-проєкті технічно можна мати і Playwright, і Selenium tests під pytest: Playwright для основного functional suite, Selenium — для вузької cross-browser перевірки. Це виправдано лише реальною вимогою, бо два automation stacks подвоюють dependency, fixture та maintenance surface.
Consumer, producer і REST resources
Звична client–server model узагальнюється термінами consumer і producer. Consumer споживає дані або можливість, producer їх надає. Така мова працює не лише для browser і web server, а й для взаємодії між сервісами. Комунікація має protocol і contract. API-документації може не бути, вона може бути написаною вручну і застарілою або code-generated з анотацій у коді. У REST сутності представлені resources, а операції над ними — endpoints з HTTP-методами `GET`, `POST`, `PUT`, `DELETE`.
SAST, DAST і спеціалізовані scanners
SAST аналізує codebase, configuration та infrastructure definitions без запуску повного user flow. До scope можуть входити source code, dependencies, YAML, Docker та Terraform files. DAST працює проти запущеного застосунку: генерує requests, змінює parameters, headers, authentication data й шукає небезпечну runtime behavior. OpenAPI specification може бути input для API security scanner-а. Окремі tools аналізують network traffic або вразливості, характерні для конкретної мови, cloud platform, protocol чи IoT stack. Тому pentesting швидко розгалужується на спеціалізації, а не зводиться до ручного перебору requests у Postman.
Selenium CDP/BiDi та version coupling
[Дивитися з 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.
Playwright як тонкий клієнт і підсумкова модель
[Дивитися з 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.