За последние пять лет в ИТ-индустрии наблюдается глупая тенденция «задвигания» тестирования на задворки.
Улучшает ли она практики, связанные со стратегией тестирования? Нет.
Обеспечивает ли она всегда «зеленый» билд, если нет ошибок? Нет.
Гарантирует ли качество автотестов? К сожалению, нет.
Способствует ли она достижению совершенства за счет командного взаимодействия и построения отношений между управлением продуктом, разработкой и QA? Мне бы очень этого хотелось.
Я вижу глупую тенденцию, когда команды выбрасывают Selenium-тесты, создававшиеся годами, и переписывают их на Playwright. Вероятно, они начитались тех идиотских кликбейтных статей, в которых сравнивают эти два фреймворка, суть которых сводится к поливанию грязью Selenium.
Реальная проблема: древние тесты и практики
Истинная причина кроется не в инструменте: это нестабильные тесты, меняющиеся требования к продукту и забагованный код тестируемого приложения (AUT).
Если ваши тесты нестабильны, совершенно неважно, стабилен ли ваш продукт: никто не будет доверять вашим автотестам. Как только доверие потеряно, его очень трудно вернуть.
Многие команды, с которыми я общаюсь, начинают переход на Playwright, не решив описанные выше проблемы. У них куча тестов, высокий процент сбоев и множество пропущенных багов. Они начинают процесс миграции, и это поначалу очень увлекательно, потому что вы получаете быстрый результат, видя, как то, что не работало в Selenium, начинает работать в Playwright.
Справедливости ради, в Microsoft проделали отличную работу, сделав Playwright чрезвычайно удобным: тесты можно разрабатывать, выполнять, отлаживать и поддерживать прямо в среде разработки (IDE), и запускать целые наборы не составляет труда.
Все это замечательно, но пропуски дефектов все еще часты, а количество тестов продолжает расти. Разработчики не хотят тратить время на поддержку тестов после того как они их написали, и мы просто откладываем решение проблемы еще на несколько месяцев.
Самые идеальные инструменты НЕ МОГУТ компенсировать отсутствие тестовой стратегии. Но в небольших проектах они могут дать тестировщикам передохнуть на достаточно долгое время, до следующего проекта. Мы называем это Resume-driven Development.
Если уж вы сравниваете инструменты, то убедитесь, что вы ищете не просто «быстрее».
Приведенная ниже таблица – не для того, чтобы выбрать, какой инструмент лучше. Она для того, чтобы помочь вам понять компромиссы, на которые вы идете.
Сравниваем вдумчиво: Selenium vs Playwright
Сходства
| Критерий | Selenium | Playwright |
| Предназначен для функционального тестирования в браузерах | Да | Да |
| Масштабируется для параллельного тестирования | Да | Да |
| Предоставляет логи, видео, скриншоты и т.д. | Да | Да |
| Использует распространенные языки программирования | Да | Да |
Различия
| Критерий | Selenium | Playwright |
| Работает ли с реальным браузером | Да. Selenium работает с реальным исполняемым файлом браузера. | Да. Может использоваться с Chrome и Edge, но в основном запускается безголово или модифицируя движок (Chromium для Chrome, Webkit для Safari, Gecko для Firefox). |
| Рекомендованный стандарт W3C | Да. Microsoft, Google, Apple и Mozilla работали с проектом Selenium для разработки отраслевого стандарта автоматизированного взаимодействия с браузером. | Нет. Использует Chrome Devtools Protocol (CDP) для взаимодействия с Chromium и эмулирующий CDP-слой для Firefox и WebKit. Используется Webkit-специфичный API для симуляции взаимодействий в Safari. |
| Поддерживается вендорами браузеров | Да. Chrome, Firefox, Edge и Safari поддерживают совместимость со стандартом WebDriver благодаря участию вендоров. | Нет. Команда Playwright поддерживает как API для взаимодействия с движками браузеров, так и языковые биндинги для Playwright. |
| Обратная совместимость | Да. Текущая версия Selenium работает со всеми версиями браузеров, начиная с 2014 года. | Нет. Версии Playwright «привязаны» к конкретным версиям браузеров. Это означает, что вы выбираете, какая версия Playwright совместима с нужной версией браузера/движка/устройства, и поддерживаете эти версии обновленными. |
| Пакетный ли фреймворк (Batch framework) | Нет. Хотя стандарт WebDriver BiDirectional находится в разработке (классический Selenium использует пакетное тестирование на стороне клиента), текущий протокол — это полный цикл REST-запроса и ответа, требующий значительного сетевого трафика. | Да. Скрипты загружаются и выполняются внутри драйвера/клиента Playwright. Это позволяет группировать несколько команд для выполнения, без необходимости обмена данными между тестовым скриптом и браузером для каждой команды. |
| Дружественный к тестированию фреймворк («Test-friendly» framework) | Нет. Selenium был создан как объективный, нейтральный метод управления браузером, где поощряется создание абстракций. | Да. Playwright был специально разработан как целенаправленный инструмент для тестирования. |
| Безголовый режим (Headless) | Нет. Хотя Selenium умеет запускать браузер в безголовом режиме, это не является его основным предназначением как полнофункционального инструмента «черного ящика». Тесты не обязательно выполняются быстрее. | Да. Все тесты Playwright по умолчанию запускаются в безголовом режиме. Когда используются «полные» исполняемые файлы для Chrome, Edge, Firefox или для webkit2 с PyPW, то вызовы оптимизируются, что делает Playwright значительно быстрее, так как большая часть работы, связанной с движком рендеринга браузера, пропускается. |
| Поддерживается ли крупной корпорацией | Нет. Selenium разрабатывается небольшой группой энтузиастов-волонтеров с момента его создания, они тратят свое свободное время на создание инструмента, используемого миллионами тестировщиков. | Да. Microsoft приняла во владением проект Playwright и вложила значительные средства в его разработку и развитие силами своих штатных инженеров и евангелистов. Вы можете читать и скачивать код, но он не является по-настоящему «открытым» в плане вклада, так как вклад вносят только члены команд Microsoft. |
Выводы
Учитывайте особенности вашего проекта, опыт команды и долгосрочную стратегию тестирования.
Для новых проектов или команд, стремящихся модернизировать свой подход к тестированию, Playwright может представить убедительные преимущества.
Для старых стабильных проектов с большой Selenium-инфраструктурой велика вероятность того, что миграция вообще не потребуется.
В остальных случаях наиболее прагматичным подходом может быть постепенная миграция или параллельное внедрение.
Я не могу сказать вам, какой путь выбрать, но я призываю критически подумать о последствиях миграции крупных фреймворков без понимания вещей, изложенных в таблице выше.
В конечном счете, лучший фреймворк – тот, который лучше соответствует процессам в вашей команде, требованиям в проекте, и способности поддерживать и масштабировать автоматизацию.
