Відеобібліотека
Пошук у нотатках курсу 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 - яка різниця →Версії Chromium, Firefox і WebKit, сумісні з установленою версією Playwright та завантажувані окремою командою playwright install.
Конкретна збірка Chromium, Firefox або WebKit, сумісна з установленою версією Playwright; package і binary встановлюються окремими кроками.
Навіщо встановлювати Playwright-браузери, як часто та чому треба оновлювати бібліотеки →Current engine, branded-channel, Firefox і WebKit support boundaries.
3. Selenium vs Playwright - яка різниця → Першоджерело ↗У підсумку відео звучить широке формулювання, що Playwright працює через DevTools protocol.
Raw CDPSession у public API підтримується лише для Chromium-based browsers; це формулювання не можна узагальнювати на Firefox і WebKit.
`list` зберігає порядок, допускає дублікати й доступ за індексом. Оператор `in` перевіряє наявність елемента. Порівняння рядків чутливе до регістру та пробілів: `Firefox`, `firefox` і `"firefox "` — різні значення, тому зовнішні дані часто треба нормалізувати.
Після першого запуску тест може впасти, якщо встановлено Python-пакет Playwright, але ще не завантажено сумісні браузери. Їх потрібно встановити окремо: ```bash playwright install ``` Якщо команда Playwright недоступна напряму, її можна запустити як Python-модуль: ```bash python -m playwright install ``` Playwright завантажує сумісні версії Chromium, Firefox і WebKit. Chromium є окремим браузерним рушієм; для перевірки саме встановленого Google Chrome його потрібно явно обрати в конфігурації.
`pip install` за `requirements.txt` встановлює Python-бібліотеку Playwright, але не гарантовано завантажує сумісні браузерні binaries. Тому після клонування проєкту окремо запускають `playwright install` або, для меншого завантаження, команду з потрібним браузером, наприклад `playwright install chromium`. Playwright керує власними сумісними збірками Chromium, Firefox і WebKit. Якщо потрібної збірки немає у його cache, запуск завершується помилкою навіть тоді, коли сам Python-пакет уже встановлений.
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.
Після зміни залежностей запускається `uv sync`, а фактично встановлена версія звіряється з lock-файлом. Якщо імпорт не працює або підтягнулась неочікувана версія, спочатку треба перевірити синхронізацію середовища, а не змінювати тестовий код навмання. Створюється pytest fixture, яка ініціалізує `webdriver.Chrome()` і повертає driver тесту. Команди тесту надходять до browser driver, а він уже керує браузером. Аналогічно можна створювати Firefox, Edge або Safari driver, але для навчального сценарію достатньо Chrome. Сучасний Selenium Manager підбирає сумісний driver автоматично, тому за звичайного локального запуску не потрібно вручну завантажувати executable й прописувати шлях. Це спрощує fixture, але версії Selenium і браузера все одно мають залишатися відтворюваними в CI.
Один `conftest.py` накопичив конфігурацію, запуск браузера, створення сторінки й app-specific fixtures. Код розділяється на модулі `config`, `playwright` та `app`, а кореневий `conftest.py` лише підключає їх через `pytest_plugins`. Технічний шар створює браузер і context; app-шар виконує login, перевіряє, що цільова сторінка завантажена, і зберігає state. Такий поділ залишає місце для Firefox або інших browser options без змішування з бізнесовими переходами.
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.