Playwright vs Selenium: гайд по современной автоматизации тестирования

🔥 Важное для QA-специалистов! 🔥
В QaRocks ты найдешь туториалы, задачи и полезные книги, которых нет в открытом доступе. Уже более 16.000 подписчиков – будь среди нас! Заходи к нам в телеграм канал QaRocks 

Анализ архитектуры для современного QA-специалиста

Selenium уже много лет считается лидером в области веб-автоматизации. Но веб изменился. Популярность динамических одностраничных приложений (SPA), написанных на React, Angular и т.д., породила новый класс проблем в тестировании: нестабильность, сложные проблемы с синхронизацией и медленные циклы обратной связи. Все это больно бьет по традиционной архитектуре Selenium.

В результате QA-команды стали изучать, насколько проверенные временем инструменты могут конкурировать с новым поколением фреймворков, созданных специально для решения современных задач.

Данная статья написана для опытных QA-специалистов, которые отлично разбираются в Selenium и интересуются стремительным ростом популярности Playwright от Microsoft. Это не банальное сравнение функционала. Наоборот, мы проведем глубокий анализ архитектуры и объясним, почему Playwright кажется гораздо быстрее и надежнее. Кроме того, мы разберем ключевые отличия в моделях взаимодействия, поделимся практическим руководством по переносу знакомых концепций (например, объектная модель страницы POM) и даже покажем, как своими глазами увидеть разницу.

Содержание

• Рассказ о двух философиях: библиотека и фреймворк
• Смена архитектурной парадигмы
• Конец нестабильных тестов: узнаем истинные причины
• Перенос навыков: история о двух объектах страницы
• Пробуем сами: практическая демонстрация
• Отбросим хайп: почему для каждого фреймворка найдется свое место
• Послесловие. Персональные ощущения в автоматизации
• Заключение. Стратегический выбор для современного QA

Рассказ о двух философиях: библиотека и фреймворк

Прежде, чем углубляться в низкоуровневую архитектуру, нужно разобраться в важнейшем высокоуровневом отличии Selenium от Playwright – в ключевой философии.

Selenium – это мощная библиотека для браузерной автоматизации. Она не считается полноценным тестовым фреймворком. Основная задача – предоставить унифицированный способ для управления веб-браузером. А чтобы получить полноценное тестовое решение корпоративного уровня, вам придется собрать фреймворк вокруг Selenium, интегрируя другие инструменты. Классический стек Selenium включает в себя:

• Ядро: Selenium WebDriver для управления браузером
• Тест-раннер: Отдельная библиотека для организации и выполнения тестов. Например, TestNG или JUnit (для Java), либо Pytest (для Python)
• Библиотека утверждений: Для проверки результатов
• Генераторы отчетов: Создание отчетов по тестам через сторонние библиотеки (ExtentReports, Allure)
• Управление драйверами: Ручная загрузка и управление драйверами браузера (но не так давно Selenium Manager упростил этот процесс).

Playwright – это, наоборот, универсальный и готовый к работе фреймворк. Он изначально проектировался как комплексное решение для сквозного тестирования. При установке Playwright вы сразу получаете целостную и готовую экосистему:

• Ядро: Мощная библиотека для браузерной автоматизации.

• Встроенный тест-раннер: @playwright/test – полнофункциональный тест-раннер с параллельным выполнением, тестовыми хуками и расширенной конфигурацией.
• Встроенная библиотека утверждений: Богатая библиотека expect с web-first утверждениями с автоматическими ретраями.
• Интегрированные инструменты: По умолчанию поставляется с набором мощных инструментов: Trace Viewer, Codegen и Playwright Inspector.
• Автоматическое управление драйверами: Playwright загружает и управляет собственными подкорректированными бинарными данными браузера. Тем самым, устраняется проблема с совместимостью драйверов.

Это фундаментальное различие в философии полностью определяет пользовательский опыт. Selenium дает гибкость для сборки максимально настраиваемого фреймворка из отдельных компонентов. Playwright предлагает целостный, интегрированный продукт, готовый к работе сразу после установки. Столь разная философия объясняется более глубоким архитектурным различием – об этом поговорим далее.

Смена архитектурной парадигмы

Фундаментальное различие между Selenium и Playwright заключается в способе их взаимодействия с браузером. Именно из-за этого оба инструмента отличаются по скорости, надежности и удобству в работе разработчиков.

Архитектура Selenium: многоуровневая модель HTTP

Архитектура Selenium построена на API WebDriver – стандарте W3C, который работает как универсальный пульт управления браузерами. Процесс взаимодействия с браузером разделен на несколько уровней и этапов:

1. Ваш тестовый сценарий (написанный на Java, Python и т. д.) отправляет команду
2. Языковая клиентская библиотека сериализует данную команду в JSON Wire Protocol
3. Эта полезная нагрузка JSON отправляется в виде отдельного HTTP-запроса в специфичный для браузера драйвер (chromedriver.exe, geckodriver.exe)
4. Драйвер, то есть отдельный исполняемый сервер, принимает HTTP-запрос, преобразует его и пересылает инструкцию браузеру
5. Браузер выполняет команду, а ответ проходит обратно через те же уровни

И это происходит для каждого взаимодействия. Клик, нажатие клавиши или проверка текста – все перечисленное является отдельным циклом HTTP-запроса/ответа.

Несмотря на надежность модели, для нее характерна задержка. Непроизводительные издержки на установление новых HTTP-соединений для каждой команды и косвенные процессы промежуточного драйвера замедляют выполнение тестов

Архитектура Playwright: современная модель WebSocket

Playwright изначально писался для устранения узких мест в HTTP-модели. В нем используется современная клиент-серверная архитектура, которая устанавливает одно постоянное WebSocket-соединение в начале теста.

1. Ваш тестовый сценарий (на TypeScript, Python и т. д.) подключается к серверу Playwright (процесс Node.js) через один WebSocket.
2. Команды отправляются в виде сообщений по постоянному WebSocket соединению. За счет этого устраняются непроизводительные затраты HTTP.
3. Сервер Playwright взаимодействует напрямую с браузером через свой нативный протокол отладки (Chrome DevTools Protocol (CDP)).
   Это соединение относится к полнодуплексным, то есть команды и события браузера могут одновременно передаваться в обоих направлениях, создавая диалог в режиме реального времени.

Такой выбор архитектуры обеспечивает скорость и мощный функционал Playwright. Постоянный поток событий из браузера – вот, что делает механизм автоматического ожидания таким интеллектуальным и надежным

Конец нестабильных тестов: узнаем истинные причины

Исходя из своего опыта, могу сказать, что самое огорчительное в автоматизации тестирования – это «нестабильный» тест. Тут важно понимать, что нестабильность теста не вызвана какой-то одной причиной. Чаще всего это комплексная проблема, которая складывается из множества причин: нестабильные тестовые среды, ненадежные бэкенд-сервисы, несогласованность тестовых данных, задержка сети и т.д.. Ни один фреймворк для тестирования не сможет магическим образом решить проблему неработающего бэкенда или неправильно настроенной среды.

И все же, нестабильность часто вызвана проблемами с синхронизацией между тестовым сценарием и динамическим UI веб-приложения. Особенно при переходе на автоматизированное UI-тестирование. Сценарий может пытаться взаимодействовать с элементом, пока тот еще не полностью загрузился/видим/интерактивен. Selenium решает данную проблему через явное ожидание: инженер должен вручную прописать условия ожидания (WebDriverWait), которые притормозят выполнение теста до готовности элемента. Решение эффективное, но разработчику придется предугадать возможные проблемы с синхронизацией.

Это как раз тот пример нестабильности, на решение которой заточен встроенный механизм автоожидания в Playwright. Прежде, чем что-либо сделать, Playwright запускает серию тщательных проверок на возможность выполнения действий и готовность элемента. Например, для действия locator.click() Playwright автоматически ждет, чтобы элемент был:

• Прикреплен к DOM
• Видим на странице
• Стабилен (то есть не анимирован)
• Включен, а не отключен
• Получал события (то есть не перекрывался другими элементами).

Playwright автоматически обрабатывает проблемы с UI-синхронизацией. Тем самым, устраняется целый класс сбоев. А инженеры могут сосредоточиться на отладке более сложных системных проблем (например, со средой или данными) и не тратить время на нестабильный код UI-синхронизации.

Перенос навыков: история о двух объектах страницы

Page Object Model (объектная модель страницы или POM) – это основа основ легко поддерживаемой автоматизации тестирования. Принципы POM также важны и в Playwright 7. Шаблон проектирования в двух инструментах одинаковый, но отличаются детали реализации. Для POM в Selenium нужна ручная синхронизация, а в Playwright она уже встроена.

Давайте реализуем объект LoginPage в обоих фреймворках и разберем отличия на примере.

POM в Selenium: синхронизация вручную с явными ожиданиями

Стандартная POM в Selenium (она на Java) хранит локаторы, а ее методы должны явно обрабатывать синхронизацию через WebDriverWait. Это необходимо для предотвращения сбоев сценария на динамических страницах.

Шаг 1: Класс Page Object в Selenium

Обратите внимание на добавление WebDriverWait и его использование в методе входа до выполнения каких-либо действий.

// pages/LoginPage.java
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.support.ui.ExpectedConditions;
import org.openqa.selenium.support.ui.WebDriverWait;
import java.time.Duration;

public class LoginPage {
    private WebDriver driver;
    private WebDriverWait wait;

    // Локаторы
    private By usernameField = By.id("user-name");
    private By passwordField = By.id("password");
    private By loginButton = By.id("login-button");
    private By errorMessage = By.cssSelector("h3[data-test='error']");

    public LoginPage(WebDriver driver) {
        this.driver = driver;
        // Инициализация ожидания wait с 10-секундным таймаутом
        this.wait = new WebDriverWait(driver, Duration.ofSeconds(10));
    }

    public void goTo() {
        driver.get("https://www.saucedemo.com/");
    }

    public void login(String username, String password) {
        // Явное ожидание видимости каждого элемента перед началом взаимодействия
        wait.until(ExpectedConditions.visibilityOfElementLocated(usernameField)).sendKeys(username);
        wait.until(ExpectedConditions.visibilityOfElementLocated(passwordField)).sendKeys(password);
        wait.until(ExpectedConditions.elementToBeClickable(loginButton)).click();
    }

    public WebElement getErrorMessage() {
        // Сначала ждет, пока отобразится сообщение об ошибке, а потом возвращает его
        return wait.until(ExpectedConditions.visibilityOfElementLocated(errorMessage));
    }
}

Шаг 2: Тест Selenium

В тестовом сценарии используется объект страницы (Page Object), но сложность ожидания скрыта внутри POM-методов.

// tests/LoginTest.java
import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.chrome.ChromeDriver;
import static org.junit.jupiter.api.Assertions.assertTrue;

public class LoginTest {
    private WebDriver driver;
    private LoginPage loginPage;

    @BeforeEach
    public void setUp() {
        driver = new ChromeDriver();
        loginPage = new LoginPage(driver);
    }

    @Test
    public void shouldDisplayErrorMessageForLockedOutUser() {
        loginPage.goTo();
        loginPage.login("locked_out_user", "secret_sauce");

        WebElement error = loginPage.getErrorMessage();
        assertTrue(error.getText().contains("Извините, этот пользователь заблокирован."));
    }

    @AfterEach
    public void tearDown() {
        driver.quit();
    }
}

POM в Playwright: встроенная функция автоматического ожидания

Теперь давайте рассмотрим ту же реализацию в Playwright. POM в Playwright хранит объекты Locator, в которые уже встроена функция автоожидания. За счет этого код сразу становится чище и надежнее.

Шаг 1: Класс Page Object в Playwright

Обратите внимание: здесь нет никакой логики ручного ожидания. Playwright обрабатывает их автоматически.

// pages/LoginPage.ts
import { type Locator, type Page } from '@playwright/test';

export class LoginPage {
  // --- Определяет локаторы (Locator) как read-only свойства класса ---
  readonly page: Page;
  readonly usernameInput: Locator;
  readonly passwordInput: Locator;
  readonly loginButton: Locator;
  readonly errorMessage: Locator;

  constructor(page: Page) {
    this.page = page;
    // --- Лучшие практики: использовать локаторы, видимые пользователю ---
    this.usernameInput = page.getByPlaceholder('Username');
    this.passwordInput = page.getByPlaceholder('Password');
    this.loginButton = page.getByRole('button', { name: 'Login' });
    this.errorMessage = page.locator('[data-test="error"]');
  }

  // --- Определяем методы действий ---
  async goto() {
    await this.page.goto('https://www.saucedemo.com/');
  }

  async login(username: string, password: string) {
    await this.usernameInput.fill(username);
    await this.passwordInput.fill(password);
    await this.loginButton.click();
  }
}

Шаг 2: Тест Playwright

Тестовый сценарий чистый и понятный. Выстроен исключительно на логике тестирования.

// tests/login.spec.ts
import { test, expect } from '@playwright/test';
import { LoginPage } from '../pages/LoginPage';

test('должен показать сообщение об ошибке для заблокированного пользователя', async ({ page }) => {
  const loginPage = new LoginPage(page);

  // 1. Выполняет действия через методы Page Object
  await loginPage.goto();
  await loginPage.login('locked_out_user', 'secret_sauce');

  // 2. Утверждения остаются в тестовом файле
  await expect(loginPage.errorMessage).toBeVisible();
  await expect(loginPage.errorMessage).toContainText('Извините, этот пользователь заблокирован.');
});

При таком пошаговом сравнении сразу видна разница. Метод loginPage.login() в Playwright изначально стабильный, поскольку в каждом его действии используется автоожидание. За счет этого писать шаблонный код WebDriverWait не нужно. Но, как мы помним, этот код необходим для стабильной работы фреймворка Selenium.

Пробуем сами: практическая демонстрация

Вам не обязательно верить мне на слово. Можете сами понаблюдать за архитектурными различиями, изучая сетевой трафик из обоих фреймворков.

1. Визуализация HTTP-трафика в Selenium

Перехватить команды, которые Selenium отправляет драйверу браузера, можно через прокси-инструмент mitmweb (веб-интерфейс для mitmproxy).

• Настройка: Установите mitmproxy и запустите его веб-интерфейс mitmweb. Затем настройте скрипт Selenium для маршрутизации трафика через порт прокси (например, localhost:8080).
• Выполнение: Запустите простой тест Selenium. Например, вход на сайт.
• Результат: В интерфейсе mitmweb вы увидите отдельный список HTTP-запросов по каждой команде. Вот и наглядное доказательство «общительной» модели запросов по командам.

На скриншоте выше показан каскад отдельных HTTP-запросов, сгенерированных простым сценарием Selenium для входа. Каждая строка представляет собой отдельный круговой цикл приема-отправки. Вы можете без труда увидеть эту цепочку: POST к /session для инициализации соединения. За ним идет другой POST к /url для команды driver.get(). Далее – POST для поиска элемента логина, следующий POST – для отправки ключей к нему и тоже самое для поля с паролем и кнопки входа. Это наглядно доказывает задержку HTTP-модели: для каждого действия требуется новая, независимая транзакция.

2. Визуализация WebSocket-трафика в Playwright

Playwright есть встроенный флаг отладки для предоставления собственного протокола связи.

• Настройка: Внешние инструменты не требуются
• Выполнение: Запустите Playwright-тест с переменной среды DEBUG=pw:api

DEBUG=pw:api npx playwright test

Результат: В консоли появляется нескончаемый поток JSON-объектов. Это не вереница отдельных HTTP-запросов, а каскад сообщений в режиме реального времени. Они передаются по единственному WebSocket-соединению, которое Playwright установил в начале теста. Вы видите более эффективную диалоговую модель.

На снимке из журнала отладки в Playwright показана кардинально другая модель. Вместо списка отдельных HTTP-запросов мы видим единый, непрерывный поток JSON-сообщений. Это необработанный диалог, который ведется через WebSocket. Исходящие команды из нашего сценария отмечаются через => (например, page.goto), а входящие ответы или события из браузера отмечаются <=. Такой непрерывный двусторонний поток информации служит наглядным доказательством более эффективной модели «интерактивного звонка». Кроме того, именно этой моделью объясняется повышенная скорость и надежность Playwright.

Отбросим хайп: почему для каждого фреймворка найдется свое место

Современная архитектура Playwright дает существенные преимущества по части скорости и надежности. Но при этом не стоит сбрасывать со счетов и Selenium. Выбор фреймворка для тестирования – стратегическое решение, которое не сводится к одному лишь сравнению функционала. Опытный инженер может создать стабильный набор тестов в любом инструменте. Главное – подобрать фреймворк, который лучше подойдет к контексту проекта, навыкам команды и целям организации.

Но если Playwright – настолько продвинутый инструмент, то почему многие успешные компании продолжают работать в Selenium? Для ответа на этот вопрос необходимо разобраться в плюсах и минусах.

Аргументы в пользу неизменной востребованности Selenium

Живучесть Selenium свидетельствует о его мощности и адаптивности. Многие организации (особенно крупные предприятия) стабильно выбирают Selenium по нескольких весомым причинам:

• Крупные инвестиции и старые системы. Многие компании в течение многих лет, а то и десятилетий, инвестировали в стабильные, многофункциональные и зарекомендовавшие себя фреймворки на базе Selenium. Для таких компаний неприемлемы финансовые и временные затраты, а также риски, связанные с полной переработкой кода. Особенно, если речь об устаревших и не часто меняющихся приложениях.
• Непревзойденная экосистема и сообщество. Selenium считается отраслевым стандартом уже более 15 лет, и поэтому может похвастаться обширной и зрелой экосистемой. Для него написано множество сторонних плагинов и интеграций, а масштабное глобальное сообщество предлагает обучающие материалы и поддержку практически при любой проблеме. Для сложных корпоративных сред это крайне важный и весомый аргумент.
• Широкая поддержка языков и браузеров: Selenium поддерживает множество языков программирования, включая Java, C#, Python, Ruby и PHP, благодаря чему организации могут пользоваться текущими навыками своих разработчиков. Кроме того, Selenium тестирует сценарии в разных браузерах, даже в более старых или редких версиях. А это крайне весомый довод для компаний с разноплановой пользовательской базой.
• Надежное тестирование на реальных устройствах. Глубокая интеграция с Appium и другими инструментами и разные поставщики облачного тестирования помогают Selenium более комплексно и обстоятельно поддерживать автоматизацию тестирования на реальных мобильных устройствах. Критически важный критерий для многих компаний.

В конце концов, «лучший» фреймворк – этот тот, который эффективно решает проблемы вашей команды. Плохо спроектированный набор тестов в Playwright может быть таким же нестабильным и сложным в сопровождении, как и плохо написанный аналог в Selenium. Кроме того, на первый план выходят навыки инженера по автоматизации. Многие успешные организации не ограничиваются выбором какого-то одного инструмента. Они стараются разумно использовать оба фреймворка: Playwright – для важнейших путей пользователей в современных приложениях, а Selenium – для обеспечения широкой совместимости и сопровождения устаревших тестовых наборов.

Послесловие. Персональные ощущения в автоматизации

Помимо технических показателей и архитектурных схем, при выборе инструментов есть еще и субъективное «чувство». О нем нельзя забывать. Впервые работая с Playwright, у меня возникло внутреннее ощущение, что все происходит слишком быстро. Я бы даже сказал, механически. Действия выполнялись со скоростью, не похожей на взаимодействие человека с браузером.

А тест на Selenium, наоборот, за счет небольших, но ощутимых пауз, ощущался более «человеческим» и подконтрольным.

Такая разница в ощущениях неслучайна. Она как раз и свидетельствует об очевидных архитектурных различиях. «Человеческие» задержки в Selenium – это наглядная иллюстрация задержек в многоступенчатой модели «HTTP для каждой команды». «Роботизированная» скорость Playwright – это результат бесперебойной, почти что непрерывной коммуникации WebSocket с браузером. То, что сначала кажется странной поведенческой особенностью, на деле оказывается продуманной основой проектирования.

Заключение. Стратегический выбор для современного QA

Проведенный выше анализ доказал, что Playwright существенно улучшил автоматизацию веб-тестов, особенно в современных приложений. Его архитектура принципиально быстрее. Она менее подвержена временным сбоям, которые приводят к нестабильности тестов. Playwright с его разноплановым функционалом и первоклассным удобством для разработчиков – весьма привлекателен для команд, начинающих работу над новым проектом.

Но командам, у которых уже есть проекты в Selenium, перейти на Playwright не так-то просто. Полная и срочная переработка кода, едва ли, станет правильным решением. Конкретно в этих случаях лучше действовать прагматично и выбрать стратегию поэтапного перехода:

• Постепенное внедрение. Начните писать на Playwright все новые автотесты. Таким образом, команда сможет наработать опыт без вреда для существующего покрытия.
• Стратегическая миграция. Определите самые ценные или самые проблематичные тестовые наборы в существующем фреймворке Selenium (например, критические регрессионные пути, тесты с известной нестабильностью и т.д.) и отметьте их для первоочередного переноса в Playwright.
• Параллельное выполнение. В переходный период настройте CI/CD пайплайны так, чтобы они запускали как устаревшие тестовые наборы из Selenium, так и новые наборы из Playwright. Так у вас получится непрерывное покрытие.

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

Перевод статьи «Playwright vs. Selenium: A QA Engineer’s Guide to Modern Test Automation».