Досвід тестувальника: Playwright vs Selenium

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!

Привіт, мене звати Едуард Таран. Уже понад три роки я працюю QA Automation Engineer. Я стежу за тим, аби продукт відповідав установленим до нього вимогам, запитам клієнтів і був зручним у користуванні.

Саме про фреймворки для проведення автоматизованих тестів я детально розповім у статті, а саме: порівняю два популярні інструменти — Playwright і Selenium. Поділюся досвідом використання і спостереженнями щодо переваг і недоліків кожного. Спробую розібратися, коли який використовувати краще.

Playwright і Selenium — схожі чи не дуже

Що спільного

Playwright і Selenium — це фреймворки, набір інструментів для автоматизованого тестування. Наприклад для написання end-to-end-тестів (наскрізне тестування програмного забезпечення від початку до кінця) чи UI-тестування (тестування інтерфейсу користувача). Ці інструменти — оболонка, яка допомагає скрипту діяти з аплікейшеном у браузері.

Нагадаю, скрипт — це код, який описує логіку для тестування конкретного продукту, а фреймворк — це інструмент, у якому є всі необхідні для роботи функції. Якщо в спеціаліста є голий код на різних мовах (JavaScript, Java), він виглядає дуже масивно, необроблено, і для нього доводиться вигадувати багато рішень. З фреймворком потрібно лише створити скрипт, а всю іншу «чорну» роботу автоматично виконує інструмент. Наприклад, скролл (прокрутка сторінки) до елементу: в Selenium треба писати кастомні (заточені під індивідуальну задачу) методи, а в Playwright це просто функція ScrollToElement. Тож тестувальнику не потрібно самостійно забезпечувати роботу з базою даних, автентифікацію, підтримку сеансів і багато іншого.

Playwright і Selenium мають схожий функціонал, тобто список дій, які можна виконати: перевірити елемент, поклікати на нього, перевірити текст, атрибути тощо.

Ні у Selenium, ні у Playwright не потрібно прив’язуватися до якоїсь сталої архітектури фреймворку. Тобто немає вимог до того, які скрипти писати та як їх розташовувати. Тестувальник самостійно обирає, як це робити, спираючись на доступні функції фреймворку.

Чесно кажучи, з приводу архітектури багато не скажу, тому що від проєкту до проєкту може відрізнятися все — які патерни використовувати, яку структуру мають фолдери, яка організація даних, що використовуються в тестах, тощо. Що стосується внутрішньої архітектури Selenium і Playwright, тобто у тому, що в них самих під капотом, — теж не зорієнтую.

Обидва інструменти легко встановити й налаштувати, тому що є гарно описана документація з прикладами та живе ком’юніті. Тобто новачку не доведеться перевернути весь Google, щоб зробити initial setup (вперше запустити й налаштувати інструмент), адже цей механізм описаний у гайдлайнах. Цього досить для старту.

Що відмінного

Критерій

Playwright

Selenium

Мова

JavaScript / TypeScript, Java, Python, C#, .NET

Python, Java, JavaScript, C#, Ruby, Php

Інсталювання

Потрібно встановити лише NodeJS. Безшовна установка

Java, автономний сервер Selenium, прив’язки до клієнтської мови і драйвери

Підтримка браузерів

Chrome, Chromium, Webkit, Chrome, Edge

Chrome, Firefox, IE, Edge Chromium (Selenium 4), Safari, Opera

Автоматизація API

Вбудована підтримка API. Не потрібно встановлювати окремі пакети

Необхідність використання бібліотек і відповідних класів для REST тощо

Звітність

Менша підтримка в порівнянні з Selenium, оскільки Playwright є досить новою розробкою

Потрібні зовнішні сервіси звітності, такі як Allure, Extent Reports тощо

Мобільне тестування

Експериментальна підтримка автоматизації для Android (Chrome для Android і Android WebView)

Доступне за допомогою Appium

Підтримка ОС

Windows, macOS, Linux

Windows, macOS, Linux, Solaris

Підтримка Test Runner Frameworks

Jest/Jasmine, AVA, Mocha, Vitest

Jest/Jasmine, Mocha, WebDriver IO, Protractor, TestNG, JUnit, NUnit

Ком’юніті

Маленьке, але активно зростає. Має комплексну документацію

Об’ємна база документації та опцій підтримки

Перфоманс і швидкість

Швидший, ніж Selenium

Повільніший, ніж Playwright

Відкритий вхід

Безплатний, з підтримкою Microsoft

Безплатний, з підтримкою великої спільноти

Розгляньмо детальніше ключові параметри.

Мови програмування

Playwright підтримує JavaScript / TypeScript, Java, Python.

Selenium також підтримує кілька мов програмування, зокрема Java, Python, C#, Ruby і JavaScript. Я працюю з JavaScript / TypeScript.

Підтримка браузерів

Тут поки що виграє Selenium, бо покриває не лише Chrome, Edge, Chromium, Webkit, але і Firefox, IE, Opera. В інтернеті пишуть, що Playwright покриває Firefox, але на практиці це не завжди працює.

Часто це не критично, адже багато браузерів застарілі й не популярні у використанні. Переважно користувачі працюють з Google Chrome, дуже маленький відсоток на певних продуктах — з Safari.

Плюс Selenium у тому, що ним можна робити run-тести на старших версіях браузера. Нещодавно наша команда хотіла провести тести на попередніх версіях Google Chrome, бо не всі користувачі регулярно його оновлюють. Playwright не може цього зробити: він бере the latest stable version і працює на ній. У Selenium можна поставити старіший Chrome Driver, щоб провести тести на тій версії браузера, яка потрібна вам.

Швидкість та перфоманс

Selenium працює з браузером ззовні. Він, грубо кажучи, повторює дії, які QA робить руками: тестувальник клікнув — інструмент послав команду «Клік», щось ввів — Selenium послав команду «Ввести».

Playwright працює зсередини браузера, тому він швидший і має більше можливостей. Він не повторює дії користувача, а приймає їх зсередини та передає аплікейшену.

Наприклад, тестувальник може відкрити панель DevTools (де будуть відображені навантаження на пам’ять, запити, помилки), лише коли перебуває всередині браузера. DevTools — це програми, що дають змогу створювати, тестувати та налагоджувати (debug) програмне забезпечення. Selenium не має доступу до всієї цієї інформації. Якщо тестувальнику потрібно переглянути якісь помилки або послати запит, це не вдасться зробити безпосередньо з аплікейшеном.

Бувають ситуації, коли потрібно завантажена сайт і щоб там уже була якась інформація заздалегідь. Наприклад, щоб у кошику був товар. З Selenium доведеться зробити певні кроки: зайти, відкрити сторінку товару, додати його в кошик. У Playwright можна просто «підкласти» дані, що в кошику вже є товар, і коли тестувальник відкриє цю сторінку, кошик буде автоматично заповненим. Деколи ця можливість може бути критично важливою.

Репортинг

За звітністю перевага стовідсотково на стороні Playwright. Він дає досить змістовний репорт, у якому можна переглянути всі кроки, виконані під час проведення тесту. Також він дозволяє зробити відео сесії, отримати скриншоти — у цілому всі можливі артефакти із запуску автотестів. Ще в ньому є вбудований html-reporter.

Також Playwright, на відміну від Selenium, дає можливість узяти логи (текстові файли, куди автоматично записані всі події, що відбувися в комп’ютерній системі) з аплікейшену. Це теж значна перевага, що допомагає виявляти та розв’язувати проблеми.

У Selenium вбудованого html-reporter немає. Його потрібно окремо знаходити, налаштовувати та встановлювати. Selenium дозволяє записувати відео, логи та робити скриншоти, але це потребує додаткового прикручування функціонала.

API-тестування

Ситуація з API дуже схожа. API-тести — це запити, які надсилаються кожного разу, коли користувач щось робить на рівні UI (інтерфейсу). Це спосіб комунікації між front-end і back-end. API-тестування — тестування цієї взаємодії.

Грубо кажучи, тестувальник не робить ніяких дій руками. Це швидкі тести, вони не дуже складні та комплексні: надсилається запит — на нього приходить відповідь, потім наступний запит і так далі.

У Playwright є вшиті функції, що допомагають використовувати API-запити. У Selenium, як і у випадку з репортерами, для цього треба мати додаткові бібліотеки. Тобто спершу підібрати потрібну, потім її встановити, й аж після цього можна буде покривати API-запити.

Ком’юніті

Playwright — це свіжий продукт, який активно розвивається, його ком’юніті продовжує зростати. Зараз воно не таке велике, як у Selenium, але дуже активне. Також можна контактувати з підтримкою: вони приймають побажання, проводять баг-фікси.

Selenium більш стабільний дорослий продукт, у якого дуже велика база користувачів. Він не такий гнучкий у плані оновлень, баг-фіксів і так далі.

Зручність

Через те, що Playwright комплексний, він зручніший, бо в ньому одразу все є. Якщо обираєте його, не потрібно думати над бібліотекою для звітності, бібліотекою для API, не треба хвилюватися, що якщо якась штука не працює, то вона ніколи не буде працювати. Інструмент розвивається, і її можуть виправити.

У Selenium потрібно багато чого докручувати вручну. Подекуди це незручно. Наприклад, у мене вже є певний пул бібліотек й інструментів, з якими я працюю, коли пишу на Selenium, але для того, щоб їх зібрати й освоїти, потрібен був час. Зараз я точно знаю, що використаю цей репортер, цю бібліотеку для одних калькуляцій, а другий репортер — для інших.

Новачку потрібно витратити багато часу на налаштування, адже знайти нормальний репортер і бібліотеку для API не так просто. Необхідно орієнтуватися, які з них підійдуть під мову, якою написаний фреймворк, які підійдуть формату продукту тощо. Вибрати є із чого, але це може бути довго і складно. Ще у новачків або людей, які не працювали із Selenium, може виникнути проблема з відсутністю чіткого бачення того, що (які атрибути) має бути в репорті та який вигляд він має мати.

Що ще треба знати про Playwright

Playwright може трохи більше, адже це новіший інструмент, він працює дещо по-іншому. З ним я працюю менше часу, аніж з Selenium, але маю позитивні враження. Він легко сетапиться, має достатньо інформації, як його використовувати та як покривати едж-кейси (проблеми або ситуації, що виникають лише за умови екстремального робочого параметра).

З мінусів: поки що він підтримує менше браузерів. Це вагомий недолік, бо якщо продукту важливо мати покриття максимальної кількості вебсерферів, то послуговуватися Playwright не вийде. Наприклад, у нашому випадку це не настільки страшно: ми маємо невеликий відсоток юзерів, що користуються браузерами, які не підтримує Playwright. Проте для деяких інших продуктів це може бути критичним.

Ще один недолік — не можна працювати з версійністю браузерів. Інструмент буде використовувати останню доступну версію.

Є нюанс у тому, що, оскільки Playwright молодший і не такий відточений, як Selenium, з ним можуть частіше виникати едж-кейси, які поки що неможливо вирішити або вони очікують на виправлення. У розробників Playwright банально було менше часу, щоб усе перевірити та пофіксити, але вони продовжують вдосконалювати продукт.

З Selenium таку ситуацію простіше вирішити, адже в того є велика база кейсів, з якими раніше працювало ком’юніті. Багато прикладів можна знайти в інтернеті.

Чому зараз багато спеціалістів використовують саме Playwright? Тому що він швидший, ніж Selenium, і функціонує трохи за іншим принципом.

Я гадаю, новачку буде простіше почати з Playwright, бо в ньому все розташоване в одному місці: інструменти (які не потрібно шукати додатково), сучасна документація (що описує багато нюансів). Наприклад, гайд, як встановити та засетапити інструмент або як створити проєкт з нуля, step by step. Хоча, як я вже згадував, інколи її може бути недостатньо для нестандартних кейсів.

Детальніше про Selenium

Я багато й довго працював із Selenium і маю позитивні враження. Це стабільна штука, з якою можна зробити гарний фреймворк, що злагоджено працює. Selenium підходить ідеально, якщо потрібно працювати саме з UI та end-to-end-тестами для front-end. Це повторення дій, які робить користувач в аплікейшені: зайти у свій кабінет, додати продукт, прибрати його з кошика, подивитися характеристики, оплатити тощо.

Головна перевага Selenium — він cтабільний. У розробників було багато часу його відточити. Він має меншу функціональність, але вона працює в 99,9 % випадків зі 100. Наприклад, ми не можемо через нього взаємодіяти з нетворками аплікейшену. Але в тих областях, що Selenium покриває, це супернадійний інструмент, у якому завжди можна бути впевненим. Також через те, що він старший, описано більше ситуацій із його застосуванням, які можна знайти в інтернеті та використати як приклад.

Завдяки Selenium я навчився багато чого робити поза фреймворком, тому що цей інструмент не дозволяв мені працювати з нашими логами й реквестами всередині браузера. Наприклад, розібрався, як працювати з API. Мені потрібно було знаходити шляхи для певних передумов (preconditions), щоб отримати інформацію і потім використовувати її всередині тестів, але не послуговуватися браузером. Тож я робив це через API-реквести або запити в базу даних. Передумови — це список необхідних підготовчих дій (налаштування програми, середовища тестування) для проведення конкретного тестування.

Чи лише для тестування можна використовувати Selenium? У цілому, так. Звісно, ми можемо їсти суп виделкою... Тобто якщо сильно постаратися, то всі інструменти можна по-різному застосовувати, але це не варте витраченого часу й ресурсу. Цей фреймворк лише для тестування.

Що не може тестувати Selenium? Back-end-частину. Її можна тестувати через API, але не безпосередньо через Selenium. Ще він не дуже добре працює з тестуванням UI-regression, тобто screen comparison (pixel by pixel). Це тестування, під час якого система позначає будь-яку різницю між двома зображеннями, навіть ту, що не помітна для ока людини. Наприклад, якщо на сайті змінився колір якоїсь іконки, такі тести покажуть різницю, навіть якщо вона лише у відтінку.

Як обрати між Playwright і Selenium

Якщо проєкт об’єднує в собі декілька видів автоматизованих тестів, то фреймворків теж може бути декілька. Є тести для front-end, є для back-end — для них можуть бути різні фреймворки. Якщо говорити саме про front-end-тести, для яких ми використовуємо Selenium та Playwright, то в такому разі обирають лише один фреймворк.

Застосовувати Playwright та Selenium разом не можна: або те, або те. Якщо ви весь час працювали на Playwright, але вам будь-яким способом потрібно опрацювати додатковий браузер, який він не підтримує, точково застосувати Selenium не вдасться. Кодова база цих інструментів різна. Тож щоб змінити інструмент, доведеться переписувати весь код. Тобто навіть якщо метод виконує одну й ту ж задачу, те, як він прописаний у фреймворці, буде відрізнятися. Можуть бути різні варіанти параметрів, різні варіанти дії цих методів.

У нас нещодавно був кейс — постала задача опрацювати версійність браузерів. У проєкті ми працюємо з Playwright, тож я витратив немало часу, щоб знайти рішення. Зрештою виявилося, що поки це неможливо, хіба якщо Playwright пофіксить це зі своєї сторони, тобто додасть таку можливість. Зараз, враховуючи всі фічі фреймворку, це неможливо.

Через це ми не можемо розширити покриття і бути впевненими, що даємо хорошу якість не тільки на останніх версіях Chrome. У нашому випадку це не сильно критично, проте в ідеалі було б добре мати таку можливість.

Такі нюанси, як те, наскільки критично мати максимальне покриття браузерів та їхніх версій, обговорюють на початку роботи з проєктом. Наша команда розуміла, що для продукту це не буде супер критичним кейсом, тому вирішили працювати з Playwright. Якби ми одразу виявили та заінвестигейтили, що цей нюанс для нас суперважливий, то робили б фреймворк на Selenium.

Висновки

Обидва інструменти зручні у використанні й мають безліч переваг. Для роботи над проєктом варто обирати той, функціонал якого дозволить реалізувати всі критично важливі для продукту цілі.

Враховуючи актуальну ситуацію по продуктах, у більшості випадків можна обирати Playwright і не переживати за версійність і браузери. Як свідчать статистика та досвід, більшість користувачів обирають Chrome. Дуже рідко трапляється великий відсоток користувачів з Safari, Firefox, Edge.

Playwright має широкий функціонал, у ньому все в одному місці. За допомогою цього інструмента можна створити екосистему, не використовуючи купу додаткових бібліотек. Якщо виникне якась проблема, можна звернутися до живого ком’юніті або підтримки, де реально отримати відповідь.

Зараз Playwright — найкраще рішення для end-to-end-тестів плюс API. Якщо потрібно працювати з мобільною версією, можна додатково застосувати WebDriverIO — систему автоматизації, створену для веб- і мобільних застосунків. Вона написана на базі Selenium (це його обгортка), але її без проблем можна використовувати для мобайл-автоматизації, якщо в проєкті працюєш з Playwright.

Playwright це перспективна штука, яку обирають більше й більше людей. Раніше, коли з’являлись нові інструменти, такі як Playwright чи Cypress, люди не до кінця розуміли, чи можна використовувати їх на своїх проєктах. Було багато ризиків: скільки проживе цей інструмент, чи буде він підтримуватися. Зараз із Playwright такої проблеми немає, він довів свою надійність.

До слова, раніше були великі надії на Cypress. Він ближчий до Playwright, аніж до Selenium: також працює з меншою кількістю браузерів, у нього є свій репортер, але він не такий розвинений, як у Playwright. У нього ще є платні версії. Cypress був дуже популярний два роки тому — це був його пік — але потім почав затухати, тож Playwright вирвався вперед.

Selenium — це інструмент саме для спілкування з браузером, а Playwright — складніша штука, яка вміщує в себе більше можливостей. Думаю, він може розростатися ще більше, тому що не фокусується тільки на браузері: і репортери під себе робить, і з аплікейшеном безпосередньо працює. Тобто намагається бути фреймворком, усі функції якого зібрані в одному місці.

👍ПодобаєтьсяСподобалось12
До обраногоВ обраному9
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Стаття містить дуже багато неточностей, я детально розповідав про те як тести керують браузером і в чому різниця CDP і вебдрайверу — youtu.be/...​TaKJA?si=f9hrOVZjcfRzOix7

Дозволю собі декілька пропозицій для правок зі своєї колокольні. Сорі за об’єм )

Playwright і Selenium — це фреймворки

Жодне з цього не є фреймворками. Playwright то бібліотека. playwright/test то фреймворк, а також є selenium based фреймворки, як webdriverIO, наприклад. У самого селеніума є по суті протокол w3c і бібліотека на його основі WebDriver.

скрипт — це код, який описує логіку для тестування конкретного продукту

Точніше було б тоді скрипт тесту

фреймворк — це інструмент, у якому є всі необхідні для роботи функції

це теж опис бібліотеки більше. фреймворк — це інструмент, який диктує порядок і правила написання нашого коду, який фреймворк буде виконувати.

в Selenium треба писати кастомні (заточені під індивідуальну задачу) методи, а в Playwright це просто функція ScrollToElement

wdio $(selector).scrollIntoView(scrollIntoViewOptions)

Ні у Selenium, ні у Playwright не потрібно прив’язуватися до якоїсь сталої архітектури фреймворку. Тестувальник самостійно обирає, як це робити, спираючись на доступні функції фреймворку.

Само слово фреймворк одразу каже, що треба. Тільки у цих випадках саме фреймворками виступають тест раннери. Ми маємо складати тести в describe, it s т.д.

Що стосується внутрішньої архітектури Selenium і Playwright, тобто у тому, що в них самих під капотом, — теж не зорієнтую.

У селеніума це webdriver protocol. У кожного браузера є свій драйвер, до якого по вище згаданому протоколу підключаєтсья селеніум і каже, що робити. У ПВ це Chrome Dev Tools protocol. По ньому ПВ підключаєтсья до браузера і керує ним.

Chrome, Chromium, Webkit, Chrome, Edge

Chrome 2 рази


Менша підтримка в порівнянні з Selenium, оскільки Playwright є досить новою розробкою

В порівняні з селеніумом так. Але це не шось прям зовсім нове.

Потрібні зовнішні сервіси звітності, такі як Allure, Extent Reports тощо

У wdio також є вбудовані репортери. Не такі класні, але є )

Jest/Jasmine, Mocha, WebDriver IO, Protractor, TestNG, JUnit, NUnit

WebDriver IO, Protractor — то фреймворки, не тест раннери.

Перфоманс і швидкість — Швидший, ніж Selenium — Повільніший, ніж Playwright

Тут маю зауважити, що то так і є, але в переважній кількості кейсів різниця в швидкості інстремунта буде абсолтно непомітною у порівнянні швидкості роботи застосунку. То на певних об’ємах тестів і поміряти не вийде, бо буде в зоні статистичної похибки

Нещодавно наша команда хотіла провести тести на попередніх версіях Google Chrome, бо не всі користувачі регулярно його оновлюють

Він же автоматично оновлюється. То шо у вас за юзери такі? )

DevTools. Selenium не має доступу до всієї цієї інформації.

Якщо я не помиляюся, то в останній версії wdio вже має можливість підключитися до браузера по cdp з коробки. До цього теж можна було, але треба присісти. Я підключав до wdio puppeteer, щоб зняти показники ram з браузера

З Selenium доведеться зробити певні кроки: зайти, відкрити сторінку товару, додати його в кошик. У Playwright можна просто «підкласти» дані, що в кошику вже є товар, і коли тестувальник відкриє цю сторінку, кошик буде автоматично заповненим. Деколи ця можливість може бути критично важливою.

У ПВ це по суті трохи спрощений інтерфейс, який працює з локал стореджем. Селеніум теж може туди покласти все, що треба через browser.setLocalStorage(key, value) (wdio). По суті та сама історія з іншим інтерфейсом. Можна зробити так, що коли відкриваєш урлу, то юзер вже в заповненому кошику навіть без логіна. При чому через setLocalStorage виходить гнучкіше, бо можна створити сутність через апі і покласти її в кошик в рантаймі, а не мати певну заготовку. ПВ теж так може.

За звітністю перевага стовідсотково на стороні Playwright. Він дає досить змістовний репорт, у якому можна переглянути всі кроки, виконані під час проведення тесту. Також він дозволяє зробити відео сесії, отримати скриншоти — у цілому всі можливі артефакти із запуску автотестів. Ще в ньому є вбудований html-reporter.

У wdio теж є вбудований html репортер з відео і скрінами. Що нема, так це трейси і це кіллер фіча ПВ

У Selenium вбудованого html-reporter немає. Його потрібно окремо знаходити, налаштовувати та встановлювати. Selenium дозволяє записувати відео, логи та робити скриншоти, але це потребує додаткового прикручування функціонала.

Знову ж таки тут порівняння фреймворка з бібліотекою. Якщо поміняти місцями і взяти playwright як бібіліотеку і wdio, як фреймворк, то буде навпаки ) І у wdio і у playwright/test є то все вбудоване і налаштування відбуваєтсья через проперті в конфізі.

У Playwright є вшиті функції, що допомагають використовувати API-запити. У Selenium, як і у випадку з репортерами, для цього треба мати додаткові бібліотеки. Тобто спершу підібрати потрібну, потім її встановити, й аж після цього можна буде покривати API-запити.

Ну ви тут, як рокет саєнс розписуєте. npm install axios і питання вирішено.

Наприклад, гайд, як встановити та засетапити інструмент або як створити проєкт з нуля, step by step.

Коли ставиш wdio, то він сходу інтерактивно в консолі питає шо ти від нього хочеш. В результаті маєш засетаплене рішення з прикладами тестів і навіть пейдж обджектами. Так що почати з ним теж не проблема.

Чи лише для тестування можна використовувати Selenium? У цілому, так.

Там вже був коментар про скрапінг, не буду повторюватися, але є питання. З ПВ якось інакше? Чи типу, якщо є вбудований кліент для апі, то можна апі тестувати і в цьому тільки відмінність?

Що не може тестувати Selenium? Back-end-частину. Її можна тестувати через API, але не безпосередньо через Selenium.

І це є дуже правильно, бо для апі тестів потрібен тільки тест раннер і апі клієнт, тому нема сенсу тягнути решту. На початку моєї кар’єри в автоматизації у нас були апі тести, які ранилися протрактором. Тобто відкривався браузер, в ньому нічого не відбувалося, а десь там поруч бігли тести. То зайве.

Ще він не дуже добре працює з тестуванням UI-regression, тобто screen comparison (pixel by pixel)

Запропоную Visual Regression замість UI-regression. А що саме не дуже?
У wdio є Image Comparison (Visual Regression Testing) Service для цього. Я його не використовував, тому цікаво. Я юзав pixelmatch в wdio тестах і ще окремо BackstopJS

Тож щоб змінити інструмент, доведеться переписувати весь код.

якщо архітектурно грамотно підійти, то можна, але це непроста тема.

питання щодо віддаленного виконання(приклад з реального проекту):
є спеціально виділена для рану веб-тестів linux ВМ, на якій встановлені браузери, вебдрайвери і селеніум сервер на 4444 і 1111 порті
команда з 8-10 людей які практично постійно одночасно ранять на ньому вебтести

як щось подібне можна відтворити у випадку використання Playwright?

поки що є така можливість playwright.dev/docs/selenium-grid
але потім це схоже буде нативніше, але в принципі можна юзати буде сайслаби всякі

хм, тоді можливо автору варто поправити трохи статтю

Застосовувати Playwright та Selenium разом не можна: або те, або те.

а зараз як? можна ранити лише на своїй локальній машині або запускати тести тоді теж з ремоут машини?

дякую за статтю!
але хочу вставити свої 5 копійок)
1. щодо підтримки мов, Playwright ентузіасти портували його також на Go — ⁠github.com/...​t-community/playwright-go
2. по популярності: ⁠Playwright має 55к зірочок на гітхабі проти 28к у Selenium, тому тут ще спірно хто популярніший зараз)
3. не дуже зрозумів поінт з інсталюванням — це який автономний сервер потрібен для Selenium? надіюсь це не про Grid?)
4. і момент з драйверами, це вже давним давно не проблема, бо є менеджер, який одним рядком коду вирішує цю проблему — колись було опенсорсне рішення (bonigarcia.dev/webdrivermanager), а тепер офіційно з коробки (www.selenium.dev/...​ntation/selenium_manager)
⁠5.

Це стабільна штука, з якою можна зробити гарний фреймворк, що злагоджено працює.

посміявся))))) варто лише згадати про StaleElementReferenceException
6. ⁠

Чи лише для тестування можна використовувати Selenium? У цілому, так. Звісно, ми можемо їсти суп виделкою... Тобто якщо сильно постаратися, то всі інструменти можна по-різному застосовувати, але це не варте витраченого часу й ресурсу. Цей фреймворк лише для тестування.

ні, це інструмент для управління браузером. крім тестування його юзають також для скрейпінгу даних

Коли я собі обирав в що влазити то переміг Playwright. На моєму тодішньому кулькуляторі він виконувався відчутно швидше ніж Selenium. І це було ну прям основною тоді фічею для мене. І загальний синтаксис був дещо більш «елегантний» за Cypress. Туди я теж дивився ну бо ж Cypress Hill і все таке :)

Playwright швидкий, бо там спеціальні збірки браузерів які робляться спеціально для нього, по факту це не зовсім той браузер з яким працює кастомер. Це звісно занчно пришвидшує роботу, але можуть бути несподівані нюанси в поведінці цієї збірки браузера

Де ви таку інфу взяли про спеціальні збірки? В документації написано, що конкретна версія PW потребує конкретних версій браузерів, а не «спеціальних збірок».

бай дефолт плейрайт качає хроміум, а не хром
хроміум має ширші можливості для розробників, але основа та сама — рушій V8

якщо захочеться робити в реальному кастомерському барузері, то тре відповідно ставити барузер руцями на машинці де запскати — та канал змінювати в лаунч опшонах

можливо моя інфа застаріла, але раніше коли робив npx playwright install то тягнулись спеціальні білди для PW. я зокрема так під віндою витягував собі білд вебкіта.

playwright.dev/...​le-chrome—microsoft-edge — тут вказано шо по дефолту PW юзає білд хроміума, але так, якшо треба то можно його навчити працювати з Google Chrome чи еджем

Playwright використовує кастомні збірки для Gecko і WebKit. Для Chromium можна брати як їх збірку, так і стандартні комерційні chrome та edge.

«це ж було вже», а взагалі здивувало, бо PW не такий вже й свіжий, працюю з ним з 2020р, комʼюніті там пристойне вже давно, всякі «едж кейси» давно вже відточені. За жодних умов би не вернувся назад на селеніум.

Також ні. Взагалі якось так вийшло, що сайпрес пройшов повз мене, а ті поодинокі спроби використовувати його завершувались ще більшим переконанням використати PW.

Дякую за статтю, корисна інформація. Найбільш цікавило питання швидкодії. Не думали провести конкретні заміри?

Я працюю з Selenium 4 і хочу зауважити, що автор залишив поза увагою DevTools у ньому. Новий Selenium має можливість вичитувати, блокувати чи навіть підробляти ріквести, які йдуть у браузері. Не без танців з бубном, правда; припускаю, що у Playwright це робиться дещо простіше.
Також потужність Selenium суттєво зростає, якщо використовувати обгортку, як-от Selenide. Це покриває більшість «велосипедів» типу того ж скроллу (але тоді звужується вибір мов програмування).

Я одразу скажу, приблизно в 6 разів швидше на реальних сайтах

На простих html нема різниці

Дивно це чути. Можливо налаштування таймаутів різне?

все банально, чому плейрайт швидше — оскільки він працює з девтулз протоколом по сокету
а селеніум по хттп з драйвером

і особливо трагіно швидше працездатність плейрайту коли запускати тести на якихось брайзер тсеках, сайс лабах — ібо сокет проти хттп на кожен пошук елемента та очікування видимості. ПО сокету плейрат отримує стан від браузера відповідь по сокету, коли селеніум пулить стан елементу по таймауту.

все банально, чому плейрайт швидше — оскільки він працює з девтулз протоколом по сокету
а селеніум по хттп з драйвером

через цю різницю, можливі якісь специфічні кейси, коли результат певної дії з веб-елементом через вебдрайвер може відрізнятися від такої ж дії, але через сокет?

Різниця полягає більше не в тому як виокнується дія, а як виконується очікування
Селеніум пінгає сторінку кожні пулніг інтервал таймаут
Плейрайт дає команду девтулзу та девтулз відповідає по сокету назад

Тобто селеніум однонаправлений, а плейрайт двонаправлену комунікацію має

власне питання якраз до як виконується дія — напр., випадки коли webdriver не може зчитати текст, бо елемент not into view, або не може нажати кнопку, бо вона заблокована якимсь поп-апом і т.п. — це все точно так само буде і з playwright і призведе до error/exception?

Звісно, але це опціонально, можна робити force: true — тоді перевірок не буде виконуватись — playwright.dev/docs/actionability

бувають випадки коли UI так написан (зазвичай бачив таке на реакті) — всі нетворк коли завершились, всі спінери та лоадери на UI вже закінчились, елемент з яким хочется інтеракції вже доступний, enabled і все таке, але коли намагаєшся з ним шось зробити, то нічого не відбувається(наприклад при кліку по кнопці нічого не відбувається) бо десь всередині ще не підчепився обробник евенту чи шось ще відбувається.
в реальному житті юзер з таким не зіткнеться, але на тому ж сайпресі часто таке бачу через швидкість з якою все відбувається, тому доводиться накручувати асершенів побільше шоб тупо протягнути час, або в крайньому випадку робити тупий wait на константний час

Це зараз часто відбуваеться через Server side rendering. Є набагато більш гуманніші способи хендлити це, наприклад в playwright є slowMo:

use: { launchOptions: { slowMo: 50 } }

я стикався з таким поки що тільки в реакт проектах і ssr там не було. але дякую за хінт

Я повірив би, якби різниця була 40%, ну хай 100%. Але в 6 раз — це точно не із-за сокетів.

Варіант це перевірити — дуже простий. Запускаете вебдрайвер і плейврайт без всяких обгорток які додають автоочікування видимості і всяке таке, робите цикл який клікае по кнопці, і записуете i++ на кожен клік. Після циклу дивитесь скільки кліків в 15 секунд часу влізло у плейврайта(з force: true/false)
  let clickCount = 0;   while(new Date().getTime() < timeout15sec) {     await page.locator('.logo').click({force: true});     clickCount++;   }   console.log('made clicks:', clickCount); // made clicks: 449, with force: true - 4188
Для вебдрайверу мені лінь міряти )

Це тест в сферичному вакуумі. В реальності у нас є час рендеренгу сторінки і час очікування елементів доки вони будуть в потрібному стані. А час виконання самого кліку займає незначний відсоток від цього.

Отут я міряв на реальних сайтах... в 6 разів прям немає різниці, але в цілому PW приємніший ))

youtu.be/...​oPGRg?si=GrI3p0RUHIVOAX8z

Дякую, відео — вогонь! Реальна різниця вийшла в 1.6 рази на користь playwright.

Підписатись на коментарі