Семь типичных ошибок при переходе с Selenium на Playwright могут оставить Java-команду с тем же набором боли: флаки, ручные ожидания и красный CI через раз. Миграция на Playwright не чинит тесты автоматически: если перенести старые паттерны один к одному, новый стек лишь быстрее показывает старые проблемы. Для русскоязычных команд это неприятная, но полезная новость: платить придётся не за библиотеку, а за переучивание инженерных привычек.
Как пишет Habr / Карьера, Tech Lead Сергей Прощаев из OTUS разобрал семь самых частых ошибок Java-миграции и привязал их к коду, который реально встречал в проектах. Его тезис звучит жёстко: команды переезжают не на новый подход, а на новый синтаксис, поэтому через месяц после старта видят знакомую картину — тесты то зелёные, то красные, а Thread.sleep снова расползается по репозиторию. Отдельный акцент сделан на Java-стеке: в отличие от JS/TS, у Playwright здесь нет встроенного раннера с фикстурами, поэтому изоляцию, создание контекстов и часть сервисной обвязки приходится собирать руками поверх JUnit или TestNG. Именно на этом месте многие и ловят первые проблемы.
Первые три ошибки бьют по скорости и предсказуемости сильнее всего. Во-первых, команды тащат в новый стек фиксированные паузы и самодельные ожидания, хотя Playwright уже умеет автоматически ждать готовности элемента перед действием и в проверках. Автор приводит простой расчёт: тест из 40 шагов с двухсекундной паузой после каждого шага теряет 80 секунд впустую; на наборе из 500 тестов это превращается в часы машинного времени за месяц. Во-вторых, вместо пользовательских локаторов остаются XPath и позиционные CSS-селекторы, которые разваливаются при любой перестановке DOM. В-третьих, Java-команды по инерции заводят один общий BrowserContext на класс, хотя именно контекст, а не браузер, в Playwright отвечает за дешёвую изоляцию. Итог предсказуем: тесты влияют друг на друга, а флаки красиво маскируются под «проблемы инфраструктуры».
Остальные четыре ошибки не менее приземлённые. Логин через UI в каждом тесте выглядит безопасно, но на деле съедает заметную часть прогона и делает форму входа единой точкой падения для всего набора тестов; Playwright для этого предлагает storageState, то есть один вход с последующим переиспользованием авторизованного состояния. Подготовка данных кликами через интерфейс вместо API делает сценарии медленными и ломкими, хотя в инструмент уже встроен APIRequestContext. Зависимость тестов от порядка запуска убивает параллелизм: один сценарий создаёт заказ, второй его удаляет, третий случайно падает, если стартовал раньше. И наконец, привычка оборачивать всё в try/catch со скриншотами вручную проигрывает трассировкам Playwright: trace viewer показывает DOM, сетевые запросы и консоль на каждом шаге, то есть ровно то, чего обычно не хватает при падении только на CI.
За всем этим стоит не религиозная война между фреймворками, а разная архитектура. Selenium живёт вокруг WebDriver и отдельного драйвера, который переводит команды теста в действия браузера; это намеренно тонкий слой, поэтому ожидания, часть синхронизации и диагностическую обвязку команды много лет достраивали сами. Playwright работает ближе к нативным протоколам браузерных движков, из-за чего получает доступ к состоянию страницы, сети и контекста без привычной прослойки. Отсюда и автоожидания, и web-first assertions, и дешёвые изолированные контексты. При этом сам Прощаев честно оговаривает важную вещь: изоляция тестов, независимые данные и разделение UI и API — хорошие практики автоматизации вообще, а не магия одного продукта. Просто в Playwright они встроены в более удобной форме.
Чтобы разговор не выглядел учебным плакатом, автор приводит и внешние кейсы. Финтех-компания Runa, работающая более чем в 30 странах и 18 валютах, после перехода с Selenium и REST Assured получила более быстрые релизы и меньше проблем с флаками за счёт параллелизма и общей инфраструктуры под UI и API. Ещё показательнее история Zenjob: около 100 Selenium-тестов и восемь параллельных Jenkins-джобов после миграции дали сокращение времени E2E-прогона примерно с 35 минут до 7. Здесь важен не маркетинговый блеск цифры, а источник роста: выигрыш дали не «новые кнопки» в API, а отказ от явных ожиданий, общего состояния и лишнего кликанья. Свои примеры Прощаев проверял на Java-ветке Playwright 1.61, которую он называет актуальной для Maven Central на июнь 2026 года.
Для разработчиков и техлидов из этого следует довольно приземлённый вывод. Миграция на Playwright — это не замена зависимостей в pom.xml, а ревизия всего тестового конвейера: как создаются данные, где живёт сессия, чем диагностируется падение и можно ли запустить любой тест отдельно от остальных. Для бизнеса вопрос ещё проще: если после перехода стоимость CI не падает, а красный билд по-прежнему не означает реальный дефект, проект заплатил за переезд, но не получил его смысла. По сути, Playwright заставляет команды вернуть автотестам утраченную репутацию рабочего сигнала, а не фонового шума, на который уже никто не смотрит.
Теперь главный вопрос для Java-команд звучит не «переезжать или нет», а «готовы ли мы перестать писать тесты по правилам старого Selenium». Миграция на Playwright в 2026 году всё чаще становится не инструментальным апгрейдом, а экзаменом на инженерную дисциплину: либо команда убирает лишнюю обвязку и получает быстрый, изолированный и читаемый набор тестов, либо просто меняет вывеску над тем же самым набором флаков.