Playwright trace
Trace містить actions, DOM snapshots, console і network details; це корисний debugging artifact, який може містити чутливі headers або payloads.
Як упровадити автоматизацію мануальному QA та довести її ефективність →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Терміни, нюанси та джерела
WebDriver BiDi
Current Selenium підтримує logging, network і script domains через bidirectional WebDriver APIs; різницю з Playwright коректніше описувати як integrated workflow та ergonomics.
Як працює проєктний білдер, ізоляція залежностей і впровадження нових інструментів →Спроєктувати runner для одного UI-suite
Намалювати маршрут від runner до application і залежностей.
Зафіксувати потрібні credentials та мінімальні network rules.
Запустити suite з обраною concurrency й записати peak CPU/RAM.
Обґрунтувати hosted або self-hosted варіант фактичними даними.
Короткий capacity та access worksheet без універсальних припущень про RAM або вартість.
Selenium уже має network і console APIs
Фраза про історично складнішу роботу Selenium з console/network лишається корисним контекстом, але Selenium 4.46 документує WebDriver BiDi domains. Поточна різниця — інтегрованість trace/mocking workflow, а не абсолютна відсутність можливості.
Як працює проєктний білдер, ізоляція залежностей і впровадження нових інструментів →Очікування network events і API mocking
Playwright може чекати завершення request або появи response під час конкретної дії. У власній обгортці автора це оформлено як `clickWithWaitForRequestFinished`: всередині викликається Playwright network wait, а дія click передається callback-ом. У документації також показані перехоплення request/response, `route` і `fulfill`, тобто можливість змінити або підмінити API response. У відео ці приклади не реалізуються повністю: головна мета — показати доступний механізм і запропонувати дослідити його в домашній роботі. Network wait корисний не лише для синхронізації UI, а й для перевірки analytics чи інших events, що мають бути відправлені після кліку. Автор радить зберігати однаковий читабельний порядок у тестах — дія, а потім очікуваний результат — навіть якщо базовий API описує wait до callback-дії.
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.
Аналіз прогону у Trace Viewer
Після прогону tracing створює ZIP archive. Автор не радить завантажувати внутрішні дані застосунку в online Trace Viewer; локально archive відкривається командою `npx playwright show-trace <path>`, для чого на машині має бути встановлений Node.js Playwright package. Trace Viewer показує стан before/after для кожної дії, screenshots, snapshot сторінки та network requests. Завдяки цьому trace може бути основним діагностичним артефактом CI-прогону й давати значно більше контексту, ніж звичайний screenshot після падіння.
Чому Playwright радить `getByRole`
`getByRole` спирається на роль і accessible name з accessibility tree. Інші user-facing locators — `getByLabel`, `getByText`, `getByPlaceholder`, `getByAltText` і `getByTitle` — шукають за відповідним видимим або описовим значенням. Усі вони читаються ближче до наміру користувача й роблять failure зрозумілішим для розробників — основної аудиторії результатів автотестів. Незначна різниця в швидкості locator неважлива порівняно з network та application latency.
Дослідження API, frontend і авторизації
Перед автоматизацією API потрібно дослідити, як із ним працює frontend. Network tab дає фактичні requests навіть тоді, коли документації немає або вона застаріла. На прикладі sign-in показано `POST` зі status `302`, що може свідчити про Backend for Frontend або gateway із власною логікою. Форма відправляє email, password, ознаку remember me і authenticity token. Якщо API не має окремого login endpoint, автотест може завантажити HTML, витягнути токен і відтворити `application/x-www-form-urlencoded` request. У відео натомість використовується задокументований API token/login flow. Автор окремо показує, що payload може бути form data або JSON.
MCP дає контекст, але не детермінізм
Playwright MCP дозволяє моделі бачити й керувати сторінкою, але код генерує сама LLM. Однаковий prompt може дати різні структури, locators і helpers, тому інструкції не гарантують підтримуваний результат. Модель також не здогадається дослідити network, data lifecycle або project architecture, якщо це явно не поставлено завданням і не надано відповідний контекст.
Як переходити з automation у pentesting
Pentesting значною мірою спирається на automation tools, network sniffers, static analysis і спеціалізовані scanners. Попередній досвід написання тестів і scripts тому корисний, але його потрібно доповнити security-моделлю: вразливостями, протоколами, trust boundaries і способами підтвердження ризику. Автор наголошує, що для цього напряму професійні сертифікації мають більшу ринкову вагу, ніж загальні QA certificates: у конкретних вакансіях, тендерах або client engagements вони можуть бути формальною вимогою. Найбезпечніший шлях — поєднати підготовку до визнаної сертифікації з лабораторною практикою, а не обмежуватися теорією.
WebDriver і двостороння модель Playwright
Selenium виконує команди через WebDriver: тест звертається до драйвера HTTP-запитами, а драйвер керує браузером. Перевірки стану та explicit waits багаторазово опитують браузер, тому на віддаленому запуску через BrowserStack або іншу інфраструктуру network latency відчутно сповільнює тести й змушує змінювати polling interval. Playwright підтримує постійний двосторонній зв'язок із браузером і отримує результат виконаної команди через WebSocket. У відео це подається як причина меншої кількості мережевих затримок, кращої поведінки на remote execution і можливості працювати з Chromium, Firefox та WebKit через спільний API.
Як знайти керівний стан у DevTools
Щоб зрозуміти, чому UI різниться, потрібно дивитися не лише на сторінку. У DevTools варто перевірити `Network`, cookies, `localStorage` і `sessionStorage` та знайти дані, які визначають активну компанію або роль. У прикладі різницю задає `companyId`: конкретний ID відкриває корпоративний контекст, а відсутнє значення — free-проєкти. Це дає точну підказку, який стан треба підготувати перед тестом.