CDPSession
Низькорівневий канал Playwright для надсилання raw Chrome DevTools Protocol methods; доступний лише для Chromium-based browsers.
Як Playwright взаємодіє з браузером через протокол →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Терміни, нюанси та джерела
Що змінилося після запису
У підсумку відео звучить широке формулювання, що 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 показує інше.
REST як architectural style і HTTP protocol
REST пояснюється як набір architectural constraints/recommendations, а HTTP — як application protocol для client–server communication. Ці терміни не є синонімами. Ресурс представляє domain entity у контракті, URI ідентифікує його, а HTTP method виражає operation. Тест має перевіряти не лише response body, а й method semantics, headers, status і state transition.
Вебсервіси, SOAP і RESTful
Вебсервіс подається як software component, через який розподілені системи обмінюються даними. SOAP оперує messages і XML contracts, тоді як RESTful services будують інтерфейс навколо resources та HTTP semantics. Автор порівнює XML, JSON, binary payloads і statefulness. Практичний висновок для тестувальника: перед автоматизацією треба визначити реальний protocol, media types і contract, а не припускати REST лише за JSON payload.
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 API придатний до роботи, але тест швидко стає багатослівним. На проєктах це часто приводить до самописних фреймворків, у яких різні Page Objects використовують різні реалізації кліку, пошуку й очікувань. Без одного спільного контракту така обгортка накопичує дублювання та ускладнює супровід. Принципи Selenium однакові для Java, Python, C#, Ruby та інших bindings: клієнт надсилає команди WebDriver, драйвер взаємодіє з браузером. Тому важливіше розуміти модель драйвера, waits, локатори й test runner, ніж запам'ятовувати лише синтаксис однієї мови.
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.
Debugger, recorder і внутрішній transport
`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-обгортка пов'язана з командами, які фактично виконує браузер.