«Playwright сейчас модный, Selenium старый, Cypress удобный». Именно так чаще всего звучит выбор фреймворка на планировании и иногда поэтому команды разгребают последствия решения, принятого за один созвон.
Я сам проходил этот выбор не один раз, и каждый раз он оказывался сложнее, чем взять модное, новенькое и интересное.
Кто есть кто
Playwright | Selenium | Cypress | |
|---|---|---|---|
Подход | Собственный драйверный слой | WebDriver Protocol | Выполнение внутри браузера + Node backend |
Языки | JS/TS, Python, Java,.NET | Практически любые | JS/TS |
Multi‑browser | Chromium, Firefox, WebKit | Любые с WebDriver | Chromium‑based + Firefox |
Mobile | Emulation + real devices через интеграции | Через Appium | Ограниченно |
Parallel execution | Отлично | Зависит от инфраструктуры | Хорошо |
Network mocking | Очень сильный | Через доп. инструменты | Хороший |
Debugging | Trace Viewer, видео, скриншоты | Обычно сторонние решения | Один из лучших UX |
Enterprise adoption | Быстро растёт | До сих пор лидер | Сильная позиция в frontend‑командах |
1. Selenium: старый, но не мёртвый
Как работает под капотом
Test code ↓ Selenium Client ↓ WebDriver protocol ↓ Browser Driver ↓ Browser
Каждая команда типа driver.findElement(By.id("login")).click(); превращается в HTTP‑запрос к драйверу браузера. Это тонкий, стандартизированный слой и именно эта тонкость одновременно сила Selenium и его главная боль.
Плюсики:
Максимальная совместимость: большой enterprise, много Java/Kotlin в стеке, десятки команд Selenium разумный выбор не потому что он технически лучший, а потому что стоимость его замены выше стоимости жизни с его недостатками.
Огромная экосистема: Grid, облачные фермы, репортеры, внутренние библиотеки, годами выстроенные вокруг конкретного стека. Переписать тестовый код не проблема. Переписать всю инфраструктуру вокруг совсем другой разговор, и часто именно инфраструктура держит команды на Selenium дольше, чем хотелось бы.
Минусы
Selenium не знает контекст приложения. Клик может упасть из‑за элемента, которого ещё нет в DOM, незавершённой анимации, перекрывающего overlay. Ответственность за ожидание лежит на инженере отсюда легендарные Thread.sleep(3000), которые кочуют из проекта в проект не потому что тестировщики не умеют писать код, а потому что фреймворк не берёт это на себя.
Когда выбирать
✅ Большой enterprise, legacy stack, много языков в команде, уже есть Selenium Grid
❌ Новый greenfield‑проект, маленькая команда, которой нужны стабильные тесты быстро
2. Cypress: лучший DX, но со своими границами
Cypress не замена Selenium, а именно другой подход в принципе. Он работает внутри браузера:
Test Runner ↓ Browser ↓ Application
Почему команды его любят
Dev experience сильный: красивые ошибки, time travel debugging, автоматические скриншоты, удобный runner. Когда тест падает, видно не сухой стектрейс, а таймлайн: visit page → click login → api failed → button disappeared. Разработчику, который пишет фичу и тут же пишет тест на неё, это ощутимо экономит время.
Где Cypress реально спотыкается и что надеюсь что изменится
Здесь стоит быть честным, а не отделываться фразой «ситуация улучшилась». Исторически у Cypress не было полноценной поддержки multi‑tab тестов, где нужно открыть новую вкладку и переключаться между ними, писались с костылями или не писались вообще. Cross‑origin навигация тоже долго была слабым местом: Cypress изначально жил в одном browser‑контексте вместе с приложением, и переход на домен, отличный от тестируемого (OAuth‑редирект на сторонний провайдер, платёжный шлюз) регулярно ломался.
Часть этого действительно закрыли появилась экспериментальная поддержка нескольких доменов и origin‑переключений. Но это по‑прежнему не то же самое, что нативная поддержка нескольких вкладок и контекстов в Playwright, где browser.newContext() даёт полностью изолированную сессию без каких‑либо танцев с доменами. Если ваш продукт активно использует сторонние редиректы (SSO, платёжные провайдеры, OAuth) учитывайте при закладывании время на то, что Cypress здесь потребует больше усилий, чем кажется на демо‑видео.
Когда выбирать
✅ Frontend‑heavy приложения, React/Vue/Angular команды, component testing, быстрый фидбек прямо в процессе разработки фичи
❌ Много cross‑domain переходов, сложные enterprise E2E, множество разных браузеров одновременно
3. Playwright: современный подход к browser automation
Playwright проектировался позже и сразу под современные веб‑приложения, без оглядки на легаси WebDriver‑стандарта.
Test ↓ Playwright API ↓ Browser Protocol ↓ Browser
Для Chromium это Chrome DevTools Protocol, для Firefox и WebKit собственные механизмы. Более тесная интеграция с движком браузера даёт возможности, которых у Selenium нет архитектурно, это не потому что Selenium написан хуже, а потому что WebDriver как стандарт сознательно остаётся тонким слоем.
Что он делает лучше всего
Auto‑waiting. await page.click('#submit') перед действием сам проверяет существует ли элемент, видим ли он, доступен ли для клика, стабилен ли layout. Разработчик перестаёт быть менеджером ожиданий вручную.
Browser contexts — изолированные сессии без общих кук и состояния:
const userA = await browser.newContext(); const userB = await browser.newContext();
Тестировать несколько ролей параллельно, без гимнастики с очисткой storage между тестами.
Network interception:
await page.route('/api/orders', route => route.fulfill({ status: 200, body: JSON.stringify(mockData) }) );
Мокать API, симулировать ошибки, тестировать edge cases то, ради чего в Selenium и Cypress приходится тащить отдельные инструменты или писать обвязку самостоятельно.
Разбор на цифрах: во что это выливается на практике
Возьмём гипотетический, но реалистичный пример команда из 4 QA‑инженеров, продукт среднего размера, около 3000 E2E‑тестов на Selenium + Java, накопленных за три года.
Текущее состояние. Полный regression‑прогон занимает 90 минут даже с параллелизацией через Grid на 8 нод. Флаки порядка 5–10% тестов падают минимум раз за неделю без изменений в продукте. Команда тратит примерно день в неделю суммарно на разбор ложных падений это уже почти четверть ставки одного инженера, просто утекающая в шум.
После миграции на Playwright (по опыту похожих кейсов, включая публичные например, у Zenjob прогон E2E‑сьюта сократился с 35 до 7 минут после ухода от explicit waits и накладных расходов драйвера): основной выигрыш даёт не переписывание тестов один в один, а архитектурные изменения auto‑waiting вместо ручных ожиданий, изолированные контексты вместо расшаренного состояния, встроенный параллелизм вместо инфраструктуры Grid, которую нужно поддерживать отдельно.
Но у этой миграции есть цена, и про неё редко пишут в сравнительных статьях: 3000 тестов не переписываются за спринт. Реалистичный темп — 50 тестов в неделю на человека с учётом ревью и стабилизации, то есть при двух выделенных инженерах миграция займёт 10+ недель, в течение которых команда поддерживает два стека параллельно. Это не блокер, но это реальные трудозатраты, которые стоит закладывать в решение, а не узнавать о них постфактум.
Вывод простой: технология окупается не сразу, а через объём. Если у вас 20 тестов то разница между фреймворками несущественна, любой закроет задачу. Если у вас 2000+ то здесь архитектурные решения фреймворка начинают определять, сколько человеко‑часов в месяц команда тратит не на поиск багов, а на обслуживание самого процесса тестирования.
Сравнение под реальные задачи
UI E2E тесты SaaS‑продукта (CRM, личный кабинет, B2B‑сервис) много async, много API, много ролей: 🥇 Playwright, 🥈 Cypress, 🥉 Selenium.
Интернет‑магазин (login → search → cart → payment → confirmation) — нужны стабильные ожидания, работа с несколькими страницами, network mocking: 🥇 Playwright.
Enterprise banking / fintech — новый проект: Playwright. Большой legacy: Selenium. Технология тут вторична, решает стоимость миграции и то, сколько команда готова заплатить временем за архитектурный выигрыш.
Frontend‑команда сама пишет тесты — 🥇 Cypress, если в продукте нет активных cross‑domain сценариев. Порог входа ниже, разработчик пишет тест сразу рядом с кодом фичи.
Mobile web — Safari, iOS, Android browsers: обычно 🥇 Playwright + device emulation. Appium остаётся отдельным инструментом для нативных сценариев, ни один из трёх фреймворков его не заменяет.
Decision tree
Новый проект? │ Да → Есть сложные E2E сценарии? │ │ │ Да → Playwright │ │ │ Нет → Frontend-команда активно пишет тесты? │ │ │ Да → Cypress │ Нет → Есть legacy Selenium? │ Да → Оставить Selenium, мигрировать постепенно, посчитав реальную стоимость миграции в человеко-неделях
Сценарий | Лучший выбор |
|---|---|
Новый web‑продукт | Playwright |
Enterprise legacy | Selenium |
Frontend testing без cross‑domain | Cypress |
Cross‑browser E2E | Playwright |
Java‑экосистема | Selenium / Playwright |
Быстрый старт | Cypress |
Большая AQA‑платформа | Playwright |
Миграция со старого стека | Selenium → Playwright, поэтапно |
Главный вывод
В 2026 году вопрос уже не звучит как что лучше Selenium или Playwright. Правильный вопрос какая архитектура автоматизации соответствует нашей системе, команде и стоимости поддержки, и готовы ли мы заплатить временем миграции за архитектурный выигрыш.
Playwright сейчас выглядит наиболее универсальным выбором для новых AQA‑платформ. Selenium остаётся сильным инструментом там, где важны стабильность и уже выстроенная enterprise‑инфраструктура, а стоимость миграции превышает стоимость текущих недостатков. Cypress занимает свою нишу там, где главный автор тестов — frontend‑разработчик, а не отдельная QA‑команда, и в продукте немного cross‑domain сценариев.
Технология не решает архитектурную проблему сама по себе. Она либо ложится на вашу систему и команду, либо создаёт новый слой миграционного долга и это стоит считать в человеко‑часах заранее, а не выяснять постфактум.
