Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Урок описує пряме Playwright coverage через Chromium, Firefox і WebKit та відносить Edge/Opera до ширшої Selenium matrix.
Поточна Playwright Python documentation перелічує Google Chrome і Microsoft Edge channels. Це branded Chromium channels, а не додаткові browser engines. Patched Firefox не є stock branded Firefox, а Playwright WebKit не є branded Safari.
3. Selenium vs Playwright - яка різниця →Поточна Chrome documentation перелічує JSON і Puppeteer-oriented built-in formats; інші formats можуть додаватися Recorder extensions. Прямий built-in Python/pytest export не заявлено.
4. Playwright плагіни та codegen →Вбудована Chrome DevTools panel для запису, replay, редагування, import і export user flows у поточній browser session.
4. Playwright плагіни та codegen →Низькорівневий канал Playwright для надсилання raw Chrome DevTools Protocol methods; доступний лише для Chromium-based browsers.
Як Playwright взаємодіє з браузером через протокол →Фіксує конкретні built-in export formats Recorder.
4. Playwright плагіни та codegen → Першоджерело ↗Пояснює record, replay, import і export user flows у DevTools.
4. Playwright плагіни та codegen → Першоджерело ↗Замість ручного написання кожного кроку можна спробувати browser extensions, які записують дії та експортують код. У Chrome Web Store є кілька інструментів: Playwright CRX, recorder-плагіни, locator assistants і генератори. Playwright CRX у демонстрації працює нестабільно: sidebar відкривається, але запис падає або зависає після взаємодії зі сторінкою. Плагін підтримує різні формати експорту, зокрема Python/pytest, але сам факт наявності формату не гарантує працездатного сценарію. Якщо інструмент поводиться так само нестабільно локально, його краще видалити, а не будувати на ньому процес.
Після зміни залежностей запускається `uv sync`, а фактично встановлена версія звіряється з lock-файлом. Якщо імпорт не працює або підтягнулась неочікувана версія, спочатку треба перевірити синхронізацію середовища, а не змінювати тестовий код навмання. Створюється pytest fixture, яка ініціалізує `webdriver.Chrome()` і повертає driver тесту. Команди тесту надходять до browser driver, а він уже керує браузером. Аналогічно можна створювати Firefox, Edge або Safari driver, але для навчального сценарію достатньо Chrome. Сучасний Selenium Manager підбирає сумісний driver автоматично, тому за звичайного локального запуску не потрібно вручну завантажувати executable й прописувати шлях. Це спрощує fixture, але версії Selenium і браузера все одно мають залишатися відтворюваними в CI.
Вбудований Chrome DevTools Recorder записує дії в уже відкритій браузерній сесії. Сценарій можна повторно програти з нормальною або зміненою швидкістю, що корисно і для ручного тестування, і для швидкого заповнення форм. Recorder експортує сценарій переважно в JavaScript-орієнтовані формати. У демонстрації немає прямого Python-експорту, тому отриманий JSON або JavaScript доведеться конвертувати й обов’язково перевіряти. Перевага інструмента — replay у поточній сесії; недолік — це не готовий Python/pytest-тест.
У спрощеній моделі Playwright спочатку запускає browser process, потім створює ізольований `BrowserContext`, а в ньому — одну або кілька `Page`. Launch options стосуються процесу браузера, context options — сесії користувача, cookies, permissions та емуляції, а `Page` представляє вкладку й виконує дії зі сторінкою. Через `channel="chrome"` можна запустити встановлений branded Chrome замість bundled Chromium. Це потрібно, коли поведінка залежить від повного браузера або медіакодеків; для більшості перевірок швидшого bundled Chromium достатньо. Маркери дають змогу виконувати `smoke` і `regression` окремо. Практичний CI flow: спочатку короткий smoke suite перевіряє, що середовище придатне до тестування, і лише після нього запускається довша regression suite.
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.
Chrome DevTools дозволяє подивитися accessibility tree й accessible name, навіть якщо значення неочевидне з HTML. Текстові locators зручні, доки labels, placeholders і переклади стабільні. Для багатомовного продукту або content, який окремо змінює контент-команда, стабільний `data-testid` часто кращий. Атрибути можуть рендеритися по-різному залежно від frontend framework, а generated classes та IDs змінюватися між builds, тому вибір залежить від реального контракту команди.
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.
[Дивитися з 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 та процес, що виконує команди.
Після першого запуску тест може впасти, якщо встановлено Python-пакет Playwright, але ще не завантажено сумісні браузери. Їх потрібно встановити окремо: ```bash playwright install ``` Якщо команда Playwright недоступна напряму, її можна запустити як Python-модуль: ```bash python -m playwright install ``` Playwright завантажує сумісні версії Chromium, Firefox і WebKit. Chromium є окремим браузерним рушієм; для перевірки саме встановленого Google Chrome його потрібно явно обрати в конфігурації.