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

Про автора

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

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

Вчуся на проєктах і час від часу лагоджу чужі стилі, які, здається, написалися самі. Подобається, коли сторінка швидко завантажується й для однієї кнопки не потрібні три збирачі.

Усі публікації автора