Selenium vs Playwright: Что Выбрать в 2026

TL;DR

• Playwright: Современный, в 2-3x быстрее, auto-waiting, Trace Viewer, поддержка Microsoft
• Selenium: 20-летний ветеран, большая экосистема, больше языков, проверен enterprise
• Скорость: Playwright выигрывает — нативные протоколы браузера vs HTTP-based WebDriver
• Стабильность: Auto-waiting Playwright снижает flaky тесты с ~8% до ~1%
• Выбирай Playwright для: новых проектов, современных веб-приложений, TypeScript/Python команд, скорости CI/CD
• Выбирай Selenium для: legacy браузеров, существующей Grid инфраструктуры, мобильного через Appium, Ruby/Kotlin

Моё мнение: Для любого нового проекта в 2026 я бы начал с Playwright. Selenium имеет смысл только при конкретных ограничениях — legacy браузеры, Appium или большой существующий тестовый набор.

Время чтения: 15 минут

Selenium доминировал в автоматизации web-тестирования два десятилетия, набрав более 31 000 звёзд на GitHub и став стандартом W3C WebDriver. Playwright появился в 2020 году — созданный бывшими инженерами Puppeteer в Microsoft — и с тех пор вырос до более 95 000 звёзд на GitHub, став одним из самых быстрорастущих тестовых проектов в истории. Согласно опросу JetBrains Developer Ecosystem 2025, распространение Playwright среди профессиональных тестировщиков значительно растёт год от года, тогда как Selenium сохраняет позиции в enterprise-средах. Архитектура Playwright основана на нативных отладочных протоколах браузеров через постоянные WebSocket-соединения, что устраняет накладные расходы HTTP-запросов per-action, делающие Selenium медленнее и более нестабильным. Согласно документации Selenium, стандарт W3C WebDriver обеспечивает кроссбраузерную совместимость и портируемость между языками — преимущества, которые по-прежнему важны в определённых enterprise-контекстах. Правильный выбор зависит от твоих ограничений: поддержка legacy-браузеров, существующая инфраструктура и стоимость миграции.

Я руководил миграциями с Selenium на Playwright в двух разных командах. Одна миграция сэкономила нам 40 минут на CI-пайплайн. Другая не стоила того — нам нужна была интеграция с Appium, которую Playwright не поддерживает. Это сравнение основано на том опыте.

Архитектура: Почему Это Важно #

Архитектурное различие между Selenium и Playwright объясняет почти все остальные различия — скорость, стабильность, отладку и дизайн API.

Selenium: Протокол WebDriver #

Selenium использует W3C WebDriver протокол на основе HTTP:

Код теста → HTTP запрос → WebDriver сервер → Драйвер браузера → Браузер
     ↑                                                              |
     └─────────────────── HTTP ответ ←─────────────────────────────┘

Каждое действие — HTTP round-trip. Кликнуть кнопку? HTTP запрос. Прочитать текст? HTTP запрос. Проверить элемент? HTTP запрос. Каждый занимает 1-5мс сетевого overhead, и это быстро накапливается по тысячам операций.

Ещё нужны отдельные исполняемые файлы драйверов — ChromeDriver для Chrome, GeckoDriver для Firefox. Несовпадение версий браузера и драйвера — частая причина падений в CI.

Playwright: Нативные Протоколы Браузера #

Playwright общается с браузерами через их нативные протоколы отладки:

Код теста → Playwright → Браузер (постоянное WebSocket соединение)

Одно WebSocket соединение остаётся открытым весь тест. Все команды идут через него — без per-action HTTP overhead. Playwright также сам управляет бинарниками браузеров, так что несовпадения версий не случаются.

Что дают нативные протоколы:

• Перехват сетевых запросов без настройки прокси
• Автоматический захват console логов, исключений и метрик производительности
• Эмуляция устройств, геолокации, разрешений и цветовых схем
• Скриншоты во время действия, а не только в точках проверки

Сравнение Функций #

Бенчмарки Скорости #

Один и тот же тестовый набор: логин, CRUD операции, поиск, валидации форм, оформление заказа. Окружение: GitHub Actions, Ubuntu runner, Chrome/Chromium.

Последовательное выполнение (100 тестов) #

Playwright в 2.7x быстрее последовательно. Разница из трёх источников: нет HTTP overhead на каждое действие, встроенный auto-waiting (нет retry loops), и быстрый запуск браузера с persistent contexts.

Параллельное выполнение (100 тестов, 4 воркера) #

Browser contexts Playwright легче, чем полные экземпляры браузера. Можно запускать 10+ параллельных воркеров на одном CI runner без проблем с памятью.

Developer Experience #

Playwright: Современный и лаконичный #

// Тест логина — Playwright (TypeScript)
import { test, expect } from '@playwright/test';

test('login with valid credentials', async ({ page }) => {
  await page.goto('/login');
  await page.getByTestId('email').fill('user@example.com');
  await page.getByTestId('password').fill('P@ssw0rd!');
  await page.getByTestId('submit').click();

  // Автоматически ждёт навигацию и элемент
  await expect(page).toHaveURL(/dashboard/);
  await expect(page.getByTestId('welcome')).toContainText('Welcome');
});

Что выделяется:

• Нет явных waits — каждый fill(), click(), expect() автоматически ждёт
• Locator API — getByTestId(), getByRole(), getByText() читаемы и устойчивы
• Web-first assertions — toHaveURL(), toContainText() автоповтор до успеха
• Изоляция тестов — каждый тест получает свежий browser context по умолчанию

// Мок сети — встроенный
await page.route('**/api/login', route =>
  route.fulfill({
    status: 200,
    body: JSON.stringify({ token: 'fake-jwt' }),
  })
);

Selenium: Многословный, но универсальный #

// Тест логина — Selenium (Java)
@Test
public void loginWithValidCredentials() {
    driver.get(baseUrl + "/login");

    WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));

    wait.until(ExpectedConditions.presenceOfElementLocated(By.id("email")))
        .sendKeys("user@example.com");

    driver.findElement(By.id("password")).sendKeys("P@ssw0rd!");

    wait.until(ExpectedConditions.elementToBeClickable(By.id("submit")))
        .click();

    wait.until(ExpectedConditions.urlContains("/dashboard"));

    String welcomeText = wait.until(
        ExpectedConditions.visibilityOfElementLocated(By.id("welcome"))
    ).getText();

    assertTrue(welcomeText.contains("Welcome"));
}

Каждое взаимодействие требует явных waits. Паттерн WebDriverWait + ExpectedConditions — это шаблон, который пишешь сотни раз. Но ты получаешь:

• Любой язык — Java, Python, C#, Ruby, Kotlin и другие
• Любой браузер — включая Safari, IE11 и мобильные через Appium
• 20 лет экосистемы — каждый вопрос уже задан и отвечен на Stack Overflow
• Доверие enterprise — проверен на безопасность и одобрен в большинстве крупных организаций

Отладка: Где Playwright Доминирует #

Это, пожалуй, самое большое практическое различие между фреймворками.

Playwright Trace Viewer #

Когда тест падает, Playwright может записать trace — полную хронологию всего, что произошло:

# Запуск тестов с трейсингом
npx playwright test --trace on

# Или только при падении (рекомендуется)
npx playwright test --trace retain-on-failure

Trace Viewer показывает:

1. Timeline — каждое действие с timestamps
2. DOM snapshots — точное состояние страницы на каждом шаге
3. Network log — каждый request/response с таймингами
4. Console output — все console.log, предупреждения, ошибки
5. Screenshots — до и после каждого действия

Можно пошагово пройти упавший тест как видео, видя точно как страница выглядела в каждый момент. Больше никакого “у меня работает” — trace захватывает всё.

VS Code расширение Playwright #

Официальное расширение VS Code добавляет:

• Живая отладка — запуск тестов с breakpoints, инспекция состояния страницы
• Pick locator — наведи на элемент, чтобы сгенерировать код локатора
• Watch mode — тесты перезапускаются при сохранении файла
• Test explorer — визуальное дерево тестов с кнопками run/debug

Отладка Selenium #

Отладка Selenium — более ручной процесс:

1. Скриншоты — настроить TakesScreenshot в teardown-хуке
2. Логи — driver.manage().logs().get("browser") для консольного вывода
3. Stack traces — стандартная отладка на уровне языка
4. Видео — нужны внешние инструменты (Allure, Selenoid и т.д.)

Когда Selenium тест падает в CI, обычно получаешь stack trace и может быть скриншот. Понять почему он упал — элемент не виден? Сетевой запрос упал? Страница всё ещё грузилась? — требует добавления инструментации и повторного запуска.

Сравнение Стоимости #

Самая большая разница в стоимости — время CI. Если платишь поминутно на GitHub Actions, преимущество Playwright в скорости переводится в реальную экономию.

Когда Выбрать Selenium #

1. Поддержка legacy браузеров — IE11 или старые версии ещё используются
2. Интеграция с Appium — нативное мобильное тестирование (iOS, Android) критично
3. Команды на Ruby или Kotlin — Playwright не поддерживает эти языки
4. Существующая Grid инфраструктура — большие инвестиции в Selenium Grid
5. Enterprise мандаты — корпоративные стандарты требуют конкретно Selenium
6. Большой существующий тестовый набор — 5000+ Selenium тестов делают миграцию непрактичной

Когда Выбрать Playwright #

1. Новые проекты — нет legacy ограничений, начни с лучшего доступного инструмента
2. Современные веб-приложения — SPA, WebSocket, Server-Sent Events, Web Workers
3. Скорость CI/CD — в 2-3x быстрее выполнение напрямую сокращает время пайплайна
4. TypeScript/Python команды — первоклассная поддержка с отличным DX
5. Проблемы flaky тестов — auto-waiting устраняет причину #1 нестабильности
6. Кросс-браузер на любой ОС — тестирование WebKit/Safari на Linux/Windows
7. API + UI тестирование — встроенный request контекст для API вызовов без браузера

Стратегия Миграции: Selenium → Playwright #

«Я рекомендую мигрировать с Selenium на Playwright, когда доля нестабильных тестов в CI превышает 5% или тест-сьют занимает более 15 минут в последовательном режиме. Если ты ниже этих порогов и Selenium стабилен — стоимость миграции не оправдана, если только тебе конкретно не нужно кроссбраузерное тестирование WebKit или разработка с TypeScript. Начни с новых тестов в Playwright и мигрируй старые попутно при рефакторинге — не как отдельный проект.» — Юрий Кан, Senior QA Lead

Фаза 1: Оценка (1-2 недели) #

• Аудит существующего тестового набора Selenium (подсчёт тестов, категоризация)
• Определить Selenium-специфичные фичи (Grid, Appium, конкретные языки)
• Оценка трудозатрат: 1-3 часа на тест для ручной конвертации
• Выбор стратегии: постепенная или полная миграция

Фаза 2: Пилот (2-4 недели) #

• Настроить Playwright рядом с Selenium
• Мигрировать 10-20 репрезентативных тестов
• Замерить улучшения скорости и стабильности
• Определить паттерны для массовой конвертации

Фаза 3: Постепенная миграция #

• Писать все новые тесты на Playwright
• Мигрировать существующие тесты при рефакторинге
• Приоритизировать flaky и медленные тесты
• Оставить Selenium для немигрируемых тестов

Частые паттерны конвертации #

// Selenium (Java)
driver.findElement(By.cssSelector(".btn")).click();
driver.findElement(By.id("input")).sendKeys("text");
String text = driver.findElement(By.className("result")).getText();
WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
wait.until(ExpectedConditions.visibilityOfElementLocated(By.id("modal")));

// Playwright (TypeScript) — эквивалент
await page.locator('.btn').click();
await page.locator('#input').fill('text');
const text = await page.locator('.result').textContent();
// Явный wait не нужен — locator actions автоматически ждут
await expect(page.locator('#modal')).toBeVisible();

AI в миграции #

AI-инструменты могут значительно ускорить миграцию Selenium → Playwright.

Что AI делает хорошо:

• Конвертация локаторов и действий Selenium в синтаксис Playwright
• Перевод Page Objects между фреймворками
• Генерация Playwright-идиоматичного кода из паттернов Selenium
• Выявление устаревших паттернов и предложение современных альтернатив
• Написание конфигурации Playwright на основе настройки Selenium Grid

Что по-прежнему нужно человеку:

• Оценка стоит ли миграция инвестиций
• Обработка кастомных расширений и плагинов Selenium
• Планирование timeline миграции и обучения команды
• Управление переходом инфраструктуры (Grid → нативный параллелизм)

Полезный промпт:

“Конвертируй этот Selenium [Java/Python] тест в Playwright [TypeScript/Python]. Используй современные Playwright локаторы (getByTestId, getByRole) вместо CSS селекторов. Убери все явные waits — Playwright автоматически ждёт. Добавь web-first assertions (toBeVisible, toHaveText). Сохрани ту же логику теста.”

FAQ #

Playwright лучше чем Selenium? #

Для большинства современного web-тестирования в 2026, да. Playwright имеет встроенный auto-waiting, который практически устраняет flaky тесты, в 2-3x быстрее выполнение через нативные протоколы браузера, и лучшую отладку с Trace Viewer. Однако Selenium остаётся лучше для команд, которым нужна поддержка legacy браузеров (IE11), нативное мобильное тестирование через Appium, или поддержка языков вроде Ruby и Kotlin. Я бы выбрал Playwright для любого нового проекта, если нет конкретного ограничения, требующего Selenium.

Стоит ли мигрировать с Selenium на Playwright? #

Мигрируй если тратишь значительное время на расследование flaky тестов, CI-пайплайны медленные, или начинаешь тестировать современные web-фичи (WebSocket, Service Workers), которые Selenium обрабатывает плохо. Не мигрируй если у тебя 5000+ стабильных Selenium тестов, зависимость от Appium для мобильного, или команда в основном на Ruby/Kotlin. Трудозатраты обычно 1-3 часа на тест. Рассмотри постепенный подход — новые тесты на Playwright, существующие остаются на Selenium.

Playwright заменяет Selenium? #

По adoption в новых проектах, в основном да. Большинство команд, начинающих с нуля в 2026, выбирают Playwright. Но Selenium не исчезает — он по-прежнему стандарт во многих enterprise, имеет самую большую экосистему и остаётся единственным вариантом для некоторых use cases (мобильный Appium, IE11, Ruby). Думай об этом как jQuery vs React: старый инструмент широко используется, даже когда новый становится стандартом.

Могут ли Playwright и Selenium работать вместе? #

Да. Самый практичный паттерн: пиши новые тесты на Playwright, оставь существующие Selenium тесты работать до миграции или вывода. Оба могут работать в одном CI-пайплайне. Стоимость — поддержка двух наборов зависимостей, двух конфигов и двух разных паттернов. Рекомендую это только как мост миграции, не как постоянную архитектуру.

Playwright быстрее Selenium? #

Да, стабильно в 2-3x быстрее. Три причины: Playwright использует persistent WebSocket соединения вместо per-action HTTP запросов, auto-waiting устраняет overhead sleep/retry, и browser contexts легче чем полные экземпляры браузера для параллельного выполнения. В моих бенчмарках 100 тестов заняли 4 минуты на Playwright vs 11.5 минут на Selenium на том же CI runner.

У кого лучше инструменты отладки? #

У Playwright, и с большим отрывом. Trace Viewer даёт полную хронологию с DOM-снимками, сетевыми логами и консольным выводом для каждого упавшего теста — как видеозапись того, что произошло. Расширение VS Code добавляет живую отладку с breakpoints. Selenium даёт stack trace и (если настроено) скриншот. Отладка flaky теста Selenium может занять часы; с трейсами Playwright — обычно минуты.

Источники: Документация Selenium WebDriver охватывает протокол W3C WebDriver, совместимость с браузерами и руководства по настройке. Документация Playwright содержит полный справочник API, настройку браузеров и лучшие практики современного web-тестирования.

Смотрите также #

• Selenium Tutorial для начинающих - Полное руководство по Selenium с нуля
• Playwright Tutorial - Современное веб-тестирование с Playwright
• Playwright: Полное руководство - Продвинутые паттерны и архитектура Playwright
• Selenium WebDriver в 2026 - Стоит ли ещё учить Selenium?
• Selenium Grid 4 - Распределённое тестирование с Selenium Grid
• Playwright vs Cypress - Сравнение современных инструментов
• Cypress vs Selenium - Классическое сравнение
• Test Automation Tutorial - Основы и стратегия автоматизации