Playwright trace
Trace містить actions, DOM snapshots, console і network details; це корисний debugging artifact, який може містити чутливі headers або payloads.
Як упровадити автоматизацію мануальному QA та довести її ефективність →Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Playwright trace
Архів записаних browser actions і diagnostic data, який Trace Viewer показує як timeline, DOM snapshots, logs, network, source і metadata test run.
3. Фікс трейсів на СІ →Playwright trace
Артефакт із recorded browser actions, DOM snapshots, network і source context, який відкривається в Trace Viewer.
4. Повертаємо traces, pytest hooks, рефакторинг дублювань у fixtures →Trace Viewer
Інструмент Playwright для аналізу записаного test run: actions, DOM snapshots, source, console, network, errors і часової шкали.
1. Налаштування Playwright та Pytest, простий репортінг →WebDriver BiDi
Current Selenium підтримує logging, network і script domains через bidirectional WebDriver APIs; різницю з Playwright коректніше описувати як integrated workflow та ergonomics.
Як працює проєктний білдер, ізоляція залежностей і впровадження нових інструментів →WebDriver BiDi
W3C protocol для двосторонніх commands та events через WebSocket connection. Специфікація визначає modules для browsing context, input, log, network і script, але станом на 2026-07-31 має статус Working Draft.
3. Selenium vs Playwright - яка різниця →Trace Viewer як запис виконання тесту
Для демонстрації навмисно ламається locator, після чого збережений `trace.zip` відкривається командою `playwright show-trace <path>`. Trace Viewer показує послідовність actions, стан сторінки до й після кожної дії, source line, console errors і network requests. Timeline допомагає побачити не лише місце падіння, а й час очікування. Виділивши потрібний інтервал, можна звузити network-події до конкретної дії. Snapshot сторінки також дозволяє перевірити DOM і locator навіть тоді, коли браузер із failed run уже закритий — наприклад, помітити завислий loader або overlay.
API як швидша test precondition
UI-сценарій має пройти довгий user journey лише для того, щоб дістатися стану, який перевіряє тест. Якщо створення або пошук проєкту не є предметом перевірки, його можна підготувати через backend API й одразу відкрити сторінку за `project_id`. Спочатку треба дослідити Network, але server-side rendering може приховати окремі XHR-запити. Тоді джерелом контракту стає офіційна OpenAPI/Swagger документація backend, а не припущення за URL інтерфейсу.
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.
Як переходити з automation у pentesting
Pentesting значною мірою спирається на automation tools, network sniffers, static analysis і спеціалізовані scanners. Попередній досвід написання тестів і scripts тому корисний, але його потрібно доповнити security-моделлю: вразливостями, протоколами, trust boundaries і способами підтвердження ризику. Автор наголошує, що для цього напряму професійні сертифікації мають більшу ринкову вагу, ніж загальні QA certificates: у конкретних вакансіях, тендерах або client engagements вони можуть бути формальною вимогою. Найбезпечніший шлях — поєднати підготовку до визнаної сертифікації з лабораторною практикою, а не обмежуватися теорією.
MCP дає контекст, але не детермінізм
Playwright MCP дозволяє моделі бачити й керувати сторінкою, але код генерує сама LLM. Однаковий prompt може дати різні структури, locators і helpers, тому інструкції не гарантують підтримуваний результат. Модель також не здогадається дослідити network, data lifecycle або project architecture, якщо це явно не поставлено завданням і не надано відповідний контекст.
Чому Playwright радить `getByRole`
`getByRole` спирається на роль і accessible name з accessibility tree. Інші user-facing locators — `getByLabel`, `getByText`, `getByPlaceholder`, `getByAltText` і `getByTitle` — шукають за відповідним видимим або описовим значенням. Усі вони читаються ближче до наміру користувача й роблять failure зрозумілішим для розробників — основної аудиторії результатів автотестів. Незначна різниця в швидкості locator неважлива порівняно з network та application latency.
Рольова модель як кандидат для окремих states
Якщо функціональність залежить від ролі, тарифу або tenant, тести доцільно групувати за відповідним станом користувача. У прикладі один акаунт має доступ до Enterprise і Free проєктів, але в реальній системі це можуть бути окремі користувачі. Перед реалізацією досліджується UI, Network, cookies та local storage. Перемикання проєкту змінює `Company ID`; додатковими спостережуваними ознаками є тексти `Enterprise subscription` і `Free subscription`.
`try` та конкретний `except`
У `try` розміщують лише операцію, яка очікувано може впасти, а `except ValueError` обробляє конкретний failure type. Широке `except Exception: pass` стирає сигнал і ускладнює debugging. Selenium, filesystem, network і parsing мають різні exception classes, які слід розрізняти.
Як знайти керівний стан у DevTools
Щоб зрозуміти, чому UI різниться, потрібно дивитися не лише на сторінку. У DevTools варто перевірити `Network`, cookies, `localStorage` і `sessionStorage` та знайти дані, які визначають активну компанію або роль. У прикладі різницю задає `companyId`: конкретний ID відкриває корпоративний контекст, а відсутнє значення — free-проєкти. Це дає точну підказку, який стан треба підготувати перед тестом.