Architecture Decision RecordЗапис архітектурного рішення: фреймворк автоматизації браузера для E2E-тестування (Playwright чи Selenium)
1. Контекст
Ми обираємо фреймворк автоматизації браузера для нашого конвеєра наскрізного (end-to-end, E2E) тестування. Цей фреймворк буде невід’ємною частиною наших процесів CI/CD, виконуючи тести, що імітують реальну взаємодію користувачів із нашою платформою. Зокрема, тести охоплюватимуть такі сценарії, як реєстрація/вхід користувача, завантаження файлів, взаємодія з дашбордами та завантаження звітів.
Як стартап, ми зосереджені на гнучкій розробці (agile) і потребуємо швидко ітерувати й розвиватися. Наша команда переважно працює з TypeScript і Python, тому можливість писати тести цими мовами є обов’язковою. Крім того, платформа містить інтерактивні діаграми та дашборди, тож критично важливо, щоб інструмент автоматизації добре підтримував насичені динамічні інтерфейси.
Двоє претендентів на це завдання — Playwright і Selenium, кожен із власними сильними сторонами та компромісами. Нам потрібно оцінити ці фреймворки на основі наведених нижче можливостей і вимог.
2. Розглянуті варіанти
- Playwright (від Microsoft)
- Selenium (від проєкту Selenium)
3. Чинники рішення
На наше рішення впливають такі чинники:
- Гнучка розробка: обраний інструмент має забезпечувати швидкі й гнучкі цикли розробки.
- Підтримка мов: нашій команді потрібна підтримка і TypeScript, і Python.
- Тестування інтерактивного інтерфейсу: обов’язкова можливість надійно тестувати інтерактивні діаграми, дашборди та динамічні елементи.
- Швидкість виконання: хоча це не головна турбота, продуктивність у конвеєрах CI/CD береться до уваги.
- Масштабованість: ми не плануємо масового масштабування найближчим часом, але хочемо переконатися, що рішення впорається з майбутнім зростанням.
- Зворотна сумісність: застарілі системи та сумісність зі старішими браузерами наразі не критичні для нашого проєкту.
- Тестування мобільних пристроїв: хоча це не найближчий фокус, фреймворк має вміти тестувати мобільні адаптивні функції або бути розширюваним для таких випадків.
- Тестування на кількох моніторах: підтримка конфігурацій із кількома моніторами — другорядна вимога, особливо якщо ми колись масштабуватимемося до тестування складніших робочих процесів користувачів.
- Тестування завантаження файлів: фреймворк має ефективно обробляти завантаження файлів — це основна вимога наших потреб у тестуванні.
4. Критерії оцінювання
- Простота використання: наскільки легко писати й підтримувати тести?
- Підтримка мов: чи підтримує фреймворк TypeScript і Python — дві мови, якими наша команда користується найчастіше?
- Тестування інтерактивного інтерфейсу: наскільки добре фреймворк обробляє складні інтерактивні інтерфейси користувача, такі як діаграми, завантаження файлів і динамічні дані?
- Інтеграція з CI/CD: наскільки добре фреймворк інтегрується зі стандартними інструментами та сервісами CI/CD?
- Підтримка різних браузерів: які браузери підтримуються і наскільки добре вони працюють?
- Продуктивність і швидкість: як швидко виконуються тести, особливо в конвеєрі CI/CD?
- Масштабованість: наскільки добре фреймворк масштабується, якщо додаватимуться нові тести чи складніші сценарії?
- Спільнота й екосистема: наскільки активна спільнота фреймворку? Чи є багато інтеграцій і розширень?
5. Міркування
5.1 Playwright
Переваги:
- Розумніший API для завантаження локальних файлів: API Playwright для роботи з локальними файлами та виконання завантаження файлів простіший і інтуїтивніший. Це полегшило б реалізацію та супровід тестів завантаження файлів.
- Синтаксис і генерація коду: Playwright має коротший і лаконічніший синтаксис. Це дає менше шаблонного коду, що покращує супровідність і ефективність розробників. Крім того, коротший синтаксис підвищує якість генерації коду за допомогою OpenAI, полегшуючи автоматичне створення тестових скриптів.
- Тестування інтерактивного інтерфейсу: Playwright чудово тестує динамічні інтерактивні вебзастосунки, наприклад із насиченими діаграмами, складною взаємодією з користувачем і оновленнями в реальному часі. Він дуже ефективно працює з WebSockets, WebRTC, shadow DOM та іншими сучасними вебтехнологіями.
- Підтримка різних браузерів: Playwright підтримує Chromium, WebKit і Firefox. Він працює стабільно в цих браузерах, що має покрити більшість наших потреб у тестуванні.
- Інтеграція з CI/CD: Playwright безшовно інтегрується із сучасними платформами CI/CD (GitHub Actions, Jenkins тощо). Він може запускати тести паралельно в різних браузерах, оптимізуючи час виконання тестів і роблячи його придатним для швидкої розробки.
- Швидкий і надійний: Playwright загалом швидший за Selenium, особливо в режимі без графічного інтерфейсу (headless), і стійкіший у роботі з асинхронними вебелементами.
Недоліки:
- Обмежене тестування мобільних пристроїв: хоча Playwright підтримує мобільну емуляцію для браузерів, у нього немає вбудованих можливостей тестування мобільних пристроїв, як-от інтеграція Selenium з Appium для справжнього мобільного тестування.
- Менша екосистема: Playwright ще новіший і менш усталений, ніж Selenium. Хоча він має спільноту, що швидко зростає, і добру документацію, у нього, можливо, ще немає такої величезної екосистеми плагінів та інтеграцій, яку пропонує Selenium.
- Обмежена підтримка браузерів: хоча Playwright охоплює основні сучасні браузери (Chrome, Safari, Firefox), його підтримка застарілих браузерів (напр., Internet Explorer) не така надійна, як у Selenium.
5.2 Selenium
Переваги:
- Довша історія та зрілість: Selenium існує вже давно й має підтверджений послужний список. Його широко використовують численні команди та галузі, що призвело до величезної екосистеми плагінів, інтеграцій і ресурсів.
- Підтримка різних браузерів і платформ: Selenium підтримує широкий спектр браузерів і версій, включно з Internet Explorer, а також може інтегруватися з різними інструментами, як-от Docker, Selenium Grid і хмарні сервіси, для розподіленого тестування.
- Тестування мобільних пристроїв: Selenium завдяки інтеграції з Appium значно надійніший для мобільного тестування, зокрема застосунків Android та iOS. Це робить його кращим вибором для проєктів із мобільним пріоритетом або значним мобільним навантаженням.
- Тестування на кількох моніторах: Selenium краще підтримує сценарії з кількома моніторами або складною взаємодією між кількома вікнами.
Недоліки:
- Складність: API Selenium багатослівніший і явніший. Хоча в деяких випадках це може бути перевагою, це означає більше коду для написання й супроводу, що може знизити гнучкість розробників — а це особливо важливо в середовищі стартапу.
- Продуктивність: Selenium загалом працює повільніше за Playwright, особливо в режимі headless. Це могло б вплинути на конвеєри CI/CD, особливо зі зростанням кількості тестів.
- Тестування інтерактивного інтерфейсу: Selenium не такий гладкий, як Playwright, у тестуванні сучасних інтерактивних вебінтерфейсів, особливо з діаграмами та оновленнями даних у реальному часі. Для надійної взаємодії з динамічним вмістом потрібно більше налаштувань і обробки.
6. Підсумок порівняння
| Можливість | Playwright | Selenium |
|---|---|---|
| Простота використання | Коротший синтаксис, інтуїтивніший для сучасних інтерфейсів | Явніший, потребує більше шаблонного коду |
| Підтримка мов | TypeScript, Python, JavaScript | TypeScript, Python, Java, Ruby, C# |
| Тестування інтерактивного інтерфейсу | Чудово для динамічних інтерфейсів реального часу | Обробляє прості інтерфейси, але багатослівніший і складніший для насиченої взаємодії |
| Тестування завантаження файлів | Розумніший API для завантаження файлів | Багатослівніший, менш інтуїтивний API |
| Інтеграція з CI/CD | Проста інтеграція з GitHub Actions, Jenkins | Сильна інтеграція з багатьма інструментами CI |
| Тестування мобільних пристроїв | Обмежене, лише емуляція | Повна підтримка через Appium |
| Підтримка різних браузерів | Chromium, WebKit, Firefox | Повна підтримка основних і застарілих браузерів |
| Продуктивність | Швидкий, оптимізований для тестування headless | Повільніший, особливо в режимі headless |
| Тестування на кількох моніторах | Обмежене | Добра підтримка конфігурацій із кількома моніторами |
| Спільнота й екосистема | Зростає, добра документація | Велика, зріла, розлога екосистема |
7. Рішення
Зваживши вимоги та компроміси, Playwright — кращий вибір для наших поточних потреб. Його розумніший API для тестування завантаження локальних файлів, лаконічний синтаксис і сильна підтримка тестування інтерактивного інтерфейсу роблять його ідеальним для нашого циклу гнучкої розробки. Той факт, що він підтримує і TypeScript, і Python, критично важливий для нашої команди, а сучасний підхід фреймворку до тестування дозволить нам писати чистий, супровідний код.
Хоча Selenium лишається чудовим інструментом, особливо для тестування мобільних пристроїв, підтримки застарілих браузерів і конфігурацій із кількома моніторами, він менш придатний для наших поточних потреб. Його багатослівність, повільніша продуктивність і складніша робота з динамічними інтерфейсами, як-от діаграми, роблять його менш оптимальним для нашого випадку.
8. Наслідки
- Негайні дії: ми впровадимо Playwright для нашого E2E-тестування, зосередившись на тестуванні користувацьких потоків, що охоплюють реєстрацію, вхід, завантаження файлів, дашборди та завантаження звітів.
- Довгострокові міркування: ми стежитимемо за розвитком екосистеми Playwright. Якщо наші потреби зміняться, особливо щодо тестування мобільних пристроїв чи підтримки застарілих браузерів, ми можемо повернутися до Selenium.
- Навчання та документація: команди розробників мають ознайомитися з API Playwright, особливо для роботи з динамічними інтерфейсами та завантаженням файлів.
- Міграція: наявні тести Selenium (якщо такі є) поступово мігрують на Playwright.