Playwright 1.65 получил поддержку Bun и отчёты с проблемными тестами

5 ноября вышел Playwright 1.65. Как пишет Хабр, в релизе появились запуск тестов через Bun, компактные отчёты и способ выполнять отдельные проверки без параллельной нагрузки. Изменилось и поведение существующих тестов: перед обновлением командам стоит проверить, на что опираются их сценарии.

Bun, отчёты и тесты без соседей

Playwright Test запускается через Bun командой bunx --bun playwright test. Флаг --bun обязателен: bunx playwright test по-прежнему использует Node.js. При таком запуске Bun сам преобразует TypeScript в JavaScript, без Babel и кеша компиляции Playwright.

Работу раннера проверяют с Bun 1.4.3 на Linux. Пока UI-режим не перезапускает тесты при изменении файлов, а --only-changed не учитывает зависимости через импорты. При запуске через Bun параметр --tsconfig и настройки JSX в tsconfig.json не влияют на тесты; пользовательские загрузчики ESM не поддерживаются. В стеке ошибок нет асинхронных кадров, названия API выводятся без имени класса, а консольный вывод тестов не попадает в трассировку и UI-режим. Команду запуска поменять легко; сложнее потом обнаружить, что привычных деталей для отладки больше нет.

Новый репортёр failures включается командой npx playwright test --reporter=failures. Во время прогона он показывает ошибки и успешные повторные попытки, в конце — сводку, но не сообщает о ходе каждого теста. Для HTML-, JSON- и JUnit-отчётов добавлен параметр onlyFailures: в них остаются тесты с неожиданными результатами, включая неожиданные успешные прохождения, нестабильные и прерванные проверки. Если тест прошёл после падения, сведения обо всех попытках сохраняются.

Встроенная блокировка -exclusive- позволяет запускать выбранный тест без параллельных проверок. Playwright сначала дожидается окончания остальных, не запускает новые во время этого теста, а затем возвращается к обычному параллельному режиму. Это пригодится при перезапуске сервера или измерении производительности: ради одного чувствительного сценария не нужно выстраивать в очередь весь набор.

Что может измениться в существующих тестах

В TypeScript-проектах важен параметр useDefineForClassFields из tsconfig.json: Playwright теперь учитывает его так же, как компилятор TypeScript. Для цели компиляции ES2022 и новее, а также без заданного target, он включён по умолчанию. Если поле класса использует свойство, объявленное в параметрах конструктора, поле может инициализироваться до присваивания этого свойства — с ошибкой TypeError. Исправить это можно переносом инициализации в конструктор либо настройкой "useDefineForClassFields": false.

Методы locator.click(), check(), tap(), fill(), clear() и selectOption() теперь ждут, пока элемент перестанет быть inert. Если атрибут остаётся на нём или родительском контейнере, операция завершится по тайм-ауту. При разделении тестов на шарды отсутствие тестов во всех шардах теперь вызывает No tests found; для допустимого пустого результата есть --pass-with-no-tests. Отдельный пустой шард не считается ошибкой, когда в других тесты есть.

Поменялись правила сопоставления cookie с URL: они приведены к RFC 6265. Cookie для конкретного хоста больше не возвращаются его поддоменам, а путь /api не совпадает с /apiv2. Учётные данные из настройки proxy используются только для прокси-сервера; для HTTP-аутентификации на сайте нужны httpCredentials. Кроме того, текст, который браузер не отображает, больше не участвует в формировании доступных имён и снимков ARIA. Результаты page.getByRole() и проверок ARIA-снимков могут измениться.

Для кеша преобразованных тестовых файлов теперь можно задать каталог через PLAYWRIGHT_TRANSFORM_CACHE_DIR, а в cdpSession.send() — передать timeout и signal. Playwright больше не тестируется на Node.js 20: разработчики рекомендуют версии 22, 24 или 26. В официальных Docker-образах Node.js 24 заменили на 26.

Что это значит для команд сайтов

Разработчикам перед обновлением полезно прогнать тесты в своей конфигурации и отдельно проверить классы TypeScript, элементы с inert, работу cookie и прокси, а также поиск элементов по доступному имени. Если тесты распределены по шардам, нужно выяснить, допускает ли пайплайн запуск, в котором не нашлось ни одного теста. Тем, кто пробует Bun, стоит заранее сопоставить его ограничения со своим способом разбирать падения.

Для владельцев сайтов и маркетологов важнее не выбор среды запуска, а то, насколько уверенно команда проверяет изменения сайта. Короткий отчёт помогает сосредоточиться на проблемных сценариях. Но после обновления привычный тест может иначе находить элемент или дожидаться, пока он станет интерактивным: такой сбой разработчикам придётся разобрать, прежде чем доверять результатам прогона.

Моё мнение: обновлять со списком проверок

Мне нравится отчёт, в котором ошибки не теряются среди успешных строк. И -exclusive- выглядит разумнее, чем делать весь набор последовательным ради одного теста, которому нужна тишина. Проверки производительности и без того не слишком любят компанию.

А вот переходить на Bun одним движением я бы не стал. Если после смены раннера исчезнут привычные подсказки при отладке, расследование падения может занять больше времени, чем сэкономил запуск. Сначала сверил бы ограничения, затем прогнал старые сценарии — особенно TypeScript и доступность. Иначе получится знакомая история: обновили инструмент, а чинить пришлось кнопку.

Источники

Откуда новость. Текст — пересказ своими словами, факты — из источника, мнение — автора.

1. Вышел Playwright 1.65: поддержка Bun, отчёты только с ошибками и изменения в запуске тестов habr.com

Об авторе

Домас из Каунаса

младший фронтенд-разработчик

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

Все публикации автора