3. Selenium vs Playwright - яка різниця

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.

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.

Локально Selenium client, driver і browser часто знаходяться на одній машині, тому додаткові HTTP round trips майже непомітні. У remote topology команди можуть пройти від CI runner до Selenium Server/Grid, далі до remote node або cloud browser і назад. Polling explicit waits множить network latency на кількість перевірок.

Географія також впливає на system behavior: CI runner, browser node і application backend у різних регіонах дають інший latency profile, ніж локальна машина. Тому green local run не доводить, що timeout достатній для Grid/BrowserStack. Remote suite треба перевірити до merge, а browser nodes за можливості розміщувати ближче до application environment.

У Playwright очікування й action orchestration потребують менше client-side polling round trips, тому modern UI suite зазвичай працює швидше й стабільніше. Але запити самої сторінки до backend однаково залежать від мережі: Playwright не прибирає latency тестованої системи.

Playwright має APIs для TypeScript/JavaScript, Python, Java і .NET. Найповніша інтеграція навколо власного runner, fixtures і reporting доступна у Playwright Test для TypeScript/JavaScript; у Python за orchestration зазвичай відповідає pytest та його plugins.

Selenium також має офіційні language bindings, які перетворюють API-виклики на WebDriver commands. Окремі команди підтримують Selenium project і browser vendors, тому version compatibility та відмінності bindings залишаються частиною експлуатації.

Обидва інструменти — великі multi-language ecosystems. Вибір мови впливає не лише на синтаксис, а й на доступність runner integrations, fixtures, reporters, tracing і швидкість появи нових можливостей.

WebDriver BiDi додає двосторонні події й команди до WebDriver ecosystem: console/network events, більш оперативний browser state та можливості, для яких односпрямованого command-response API недостатньо. У відео технологія описується як така, що ще потребує узгодження версій Selenium, browser і driver та не має однакової зрілості у всіх language bindings.

Фінальне порівняння: Playwright — менше ручних waits, багаті debugging artifacts і швидкий workflow для сучасних engines; Selenium — ширша browser/vendor compatibility, але більше інфраструктурних і synchronization витрат. Вибір робиться від support matrix, geography, потрібних protocols і вартості maintenance, а не від загальної популярності інструмента.

Практичний default для курсу — Playwright. Selenium варто додавати лише тоді, коли конкретний browser або remote provider є перевіреною вимогою, яку Playwright suite не закриває.