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

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до 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 підтримує 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 — складніша штука, яка вміщує в себе більше можливостей. Думаю, він може розростатися ще більше, тому що не фокусується тільки на браузері: і репортери під себе робить, і з аплікейшеном безпосередньо працює. Тобто намагається бути фреймворком, усі функції якого зібрані в одному місці.