Playwright

Дванадцять маршрутів магазину в Playwright на одному екрані — механізм, на який спирається кожен

Ніхто не відкриває сторінку про Playwright заради його історії. Її відкривають, коли треба написати набір або полагодити його, і корисне питання тут конкретне: що потрібно кожному маршруту від інструмента і яка частина інструмента це дає? Нижче — дванадцять маршрутів зі сторінки «Наскрізне тестування», той самий інтернет-магазин і той самий час, — так, як магазин пише їх на Playwright. Четверта колонка називає механізм, на який спирається кожен маршрут. Розділи після таблиці пояснюють, звідки береться кожен механізм, і посилаються на маршрути за номерами, а на конфігурацію нижче — за рядками.

Таблиця каже, що робить кожен маршрут. Конфігурація нижче каже, як ідуть усі дванадцять: де, у яких браузерах, скільки водночас і що відбувається, коли один падає. Кожен рядок — рішення, яке магазин ухвалив свідомо, і для кожного є розділ нижче.

1. 1.Де він працює

   1. 1.1baseURL береться із середовища, зібраного для цього мерджу з артефакту, що йде в реліз, — ніколи не спільна адреса стейджингу.
   2. 1.2timezoneId і locale зафіксовані, тож дата й ціна в євро форматуються однаково на кожній машині.
   3. 1.3Аналітику, карти й маркетинговий чат заблоковано через context.route() у спільній фікстурі: це запити браузера, від яких не залежить результат жодного маршруту.

2. 2.Проєкти

   1. 2.1setup логінить агента підтримки й зберігає стан у playwright/.auth/agent.json, який є в .gitignore.
   2. 2.2chromium проганяє всі дванадцять маршрутів на кожен мердж, після setup.
   3. 2.3webkit проганяє маршрут 2 на кожен мердж і всі дванадцять уночі; firefox іде лише вночі.

3. 3.Скільки водночас

   1. 3.1Один маршрут на файл, fullyParallel: true, workers: 4 у CICI/CDContinuous Integration / Continuous Delivery — автоматична збірка й доставкаКожен коміт автоматично складається і проганяється через тести (CI), а придатна збірка так само автоматично їде на сервери (CD). Сенс не в автоматизації як такій, а в тому, що поломку видно за хвилини, а не в день релізу.Докладніше в статті →Усі терміни — розмір, під який зібране тестове середовище.
   2. 3.2forbidOnly: true у CI, тож забутий test.only валить запуск, а не тихо пропускає одинадцять маршрутів.

4. 4.Коли один падає

   1. 4.1retries: 1 у CI з retryStrategy: 'isolated', тож повтор іде сам наприкінці, а не поруч із наступним маршрутом.
   2. 4.2trace: 'on-first-retry', і траса вивантажується як артефакт збірки.
   3. 4.3Маршрут, позначений як flakyflakyто падає, то ні на тому самому кодіТест, що на незмінному коді то проходить, то падає. Справжня шкода не в самому падінні, а в тому, що з нього випливає: щойно таких стає кілька, люди починають перезапускати до зеленого — і набір тестів перестає бути доказом чого завгодно.Докладніше в статті →Усі терміни двічі за тиждень, іде в карантин — правило зі сторінки «Регресійне тестування».
   4. 4.4@playwright/test закріплено на точній версії й оновлюють окремою зміною, бо оновлення змінює й браузери.

Одне зʼєднання поза процесом — і які браузери ви насправді тестуєте

Ваш тест виконується у власному процесі Node.js. Playwright запускає поруч браузер і тримає з ним одне зʼєднання відкритим увесь запуск. Для браузера, який він запустив сам, це канал (pipe) між двома процесами; щоб дістатися браузера на іншій машині — WebSocketWebSocketпостійний двосторонній звʼязокЗʼєднання, що лишається відкритим в обидва боки: на відміну від HTTP, сервер може надіслати повідомлення сам, не чекаючи запиту. На ньому тримаються чати й живі стрічки — і більшість того, що виглядає як сторінка, що оновлюється сама.Усі терміни. Кожна інструкція йде вниз цим зʼєднанням, і кожна подія повертається ним угору. Для Chromium мова на дроті — Chrome DevTools ProtocolChrome DevTools Protocolяк інструменти керують ChromeПротокол, яким інструменти розробника Chrome оглядають браузер і керують ним; до нього може підʼєднатися будь-яка програма. Інструменти тестування, як-от Playwright і Puppeteer, керують через нього Chromium, тож бачать стан браузера напряму, а не крізь сторінку.Усі терміни. Для Firefox і WebKit Playwright постачає власні збірки, пропатчені так, щоб говорити його протоколом.

Ця одна схема пояснює найвідоміші властивості інструмента. Оскільки драйвер бачить стан браузера напряму, а не крізь сторінку, він може оглянути елемент перед дією й почекати, доки дія матиме сенс, — розділ 3. Оскільки все йде одним зʼєднанням, увесь запуск можна записати й відкрити пізніше, — розділ 6. І оскільки одиниця ізоляції — контекст браузера, а не браузер, чиста сесія коштує мілісекунди, а не запуск браузера, і саме це робить справжню паралельність доступною, — розділ 4.

Патчі пояснюють факт, що дивує людей. Playwright не керує Firefox чи Safari, встановленими на вашій машині: його документація каже, що він не працює з брендовою версією жодного з них, бо покладається на патчі. А «Chromium» означає різні бінарні файли в різних режимах. Таблиця показує, що запускається насправді.

Автоочікування: шість перевірок перед кожною дією — і дві речі, яких вони не виправлять

Найчастіша причина ненадійності браузерного тесту — він діяв або перевіряв раніше, ніж застосунок був готовий. У 2021 році Романо з колегами прочитали 235 нестабільних UIUIUser Interface — те, що бачить користувачУсе, що користувач бачить і чим керує: екрани, кнопки, поля, стани. UI відповідає за те, ЯК виглядає взаємодія; чи має вона сенс узагалі — це вже питання UX, і ці два поняття плутають постійно.Усі терміни-тестів із 62 веб- і Android-проєктів і простежили причину кожного. 105 із них, 45,1%, виявилися проблемами очікування, а лише у вебпроєктах ця частка становила 52%. Старіші інструменти відповідали на це паузами й ручними очікуваннями, тобто здогадкою в одязі коду. Playwright відповідає перевірками, які запускає перед кожною дією проти елемента таким, яким він є цієї миті, і повторює їх, доки вони не пройдуть або не спливе тайм-аут дії.

Друга половина моделі — локатор. Локатор не є елементом. Це опис того, як його знайти, і він розвʼязується заново щоразу при використанні, тож на сторінці, що перерендерюється під тестом, він знаходить поточний елемент, а не тримає вузол, якого вже немає. Перевірки на локаторі працюють так само: повторюються, доки умова не виконається, типово пʼять секунд. Для умови, якої взагалі немає на сторінці, — листа в тестовій скриньці, запису на складі — expect.poll повторює функцію, доки її результат не пройде перевірку, і саме так маршрути 3 і 9 чекають без жодної паузи.

Контексти, воркери й чотирихвилинний запуск

Кожен тест типово отримує свіжий контекст браузера: жодних спільних cookie, жодних залишків у сховищі, жодної залежності від порядку між маршрутами. Це тиха причина, чому набори Playwright лишаються стабільними, коли ростуть. Найчастіше джерело «окремо проходить, у наборі падає» прибирає типова поведінка, а не дисципліна.

Паралельність дають воркери. Воркер — процес операційної системи з власним браузером; воркери не можуть спілкуватися між собою, і воркер завершують після будь-якого падіння тесту, тож наступний тест ніколи не успадковує зламаний браузер. Файли тестів ідуть паралельно на різних воркерах, а тести всередині одного файлу — по порядку в одному воркері, якщо не ввімкнено fullyParallel. Магазин тримає один маршрут на файл і все одно вмикає його (рядок 3.1 конфігурації), тож одиниця, яку роздає планувальник, — один маршрут.

• Увійти раз, використати всюди

  Підготовчий проєкт логіниться й зберігає стан сховища; тести, яким потрібна ця особа, стартують із ним. Документація радить так робити для тестів, що не змінюють стан на сервері, і по акаунту на воркер — для тих, що змінюють.

• Фікстури замість коду підготовки

  Фікстура — названа річ, яку просить тест: залогінена сторінка, засіяне замовлення, API-клієнт. Її будують на вимогу й прибирають після, тож маршрут оголошує, що йому потрібно, а не облаштовує це.

• Блокування для того, що не можна ділити

  З версії 1.63 тест може тримати іменоване блокування: тести з тим самим блокуванням ніколи не йдуть водночас — між файлами, воркерами й проєктами, — а все інше лишається паралельним. Це для того одного зовнішнього акаунта, що не витримує двох авторів змін.

• Шарди й перемішування, щоб знайти залежність

  Той самий набір ділиться між машинами CI через --shard=1/3, а звіти потім зливаються. З версії 1.64 --shuffle запускає тести у випадковому порядку з seed для повтору — так виявляється тест, що тихо залежить від іншого.

Чого тест може дістати, крім сторінки, — і де це закінчується

Три можливості, крім кліків, змінюють те, що взагалі належить маршруту. Перша — API-клієнт. Фікстура request надсилає запити з тесту, а page.request ділить cookie контексту браузера в обидва боки, тож маршрут може підготувати стан через API за пʼятдесят мілісекунд і потім перевірити одну річ у браузері. Друга — маршрутизація мережі: запити сторінки можна спостерігати, затримувати, відповідати на них із записаного HAR-файлу або блокувати. Третя — годинник, що замінює Date, таймери й анімаційні кадри сторінки годинником, яким керує тест.

Падіння, яке можна відкрити: траси, повтори й позначка flaky

Дорога частина наскрізного падіння — рідко саме падіння. Це година спроб відтворити його на ноутбуці, де воно не стається. Відповідь — траса, і саме це налаштування варто зробити правильно раніше за будь-яке інше. Траса записує кожну дію зі знімком сторінки до й після неї, мережевий лог, консоль і рядок коду. Магазин пише її на першому повторі (рядок 4.2 конфігурації) і вивантажує разом зі збіркою. Вона відкривається локально або на trace.playwright.dev, який, за документацією, завантажує трасу повністю в браузері й нічого нікуди не передає.

Траса на схемі — маршрут 9 у вівторок. Перша спроба впала, повтор пройшов, тож звіт каже flaky, — а саме для повтору магазин і пише трасу. Вона показує, що гроші повернено на сторінці на 1,4 секунди, тобто магазин свою роботу зробив. Вона показує, що опитування скриньки вісім разів повернулося порожнім, а лист прийшов на 4,6 секунди — при типовій межі опитування 5,0. Першій спробі просто забракло цих останніх 0,4 секунди. Нікому не довелося нічого відтворювати, і діагноз — тайм-аут, а не продукт. Виправлення — межа, написана під умову, 15 секунд, бо 99-й перцентиль поштового конвеєра — близько девʼяти, і ніколи не пауза перед опитуванням.

Повтори — місце, де набір тихо бреше. Playwright позначає тест, що впав і пройшов на повторі, як «flaky», а не «passed», і типово запуск однаково завершується зеленим; --fail-on-flaky-tests робить його червоним. Магазин тримає один повтор, запускає його сам наприкінці з retryStrategy: 'isolated', щоб повтор не змагався з наступним маршрутом за середовище, і рахує позначки flaky як окремий сигнал (рядки 4.1 і 4.3 конфігурації). З версії 1.57 HTML-звіт має ще й вкладку Speedboard, що сортує тести за повільністю, — перше місце, куди дивитися, коли чотири хвилини стають сімома.

• Користуйтеся інтерактивним режимом, --ui, під час написання маршруту: запуск стає на паузу, локатор під курсором підсвічується, і можна спробувати інший на живій сторінці.
• Ставтеся до записаного коду як до чернетки. Запис сценарію швидко дає робочі локатори, і вони майже завжди крихкіші за ті, які ви обрали б свідомо.
• З версії 1.56 Playwright постачає три визначення агентів для асистентів програмування: планувальник, що досліджує застосунок і пише план тестів, генератор, що перетворює план на тести, і «лікар», що проганяє набір і лагодить тести, які падають.

Чотири зміни під робочими наборами

Жодна з цих змін не скандал. Кожна — датована зміна в Playwright чи в браузерах під ним, опублікована тими, хто її зробив, і кожна відділила набори, що закріплювали й оновлювали версії свідомо, від тих, що ні. Вони тут, бо браузерний тест залежить не лише від власного коду, і ці чотири показують, від чого ще.

Де він не допомагає і як порівнюється

Playwright — розумний вибір за замовчуванням для нового браузерного набору у 2026 році, а значення за замовчуванням заслуговує, щоб його застереження назвали прямо, а не виявили на третій місяць.

• WebKit не є Safari. Це той самий рушій, пропатчений і зібраний з основної гілки WebKit, без браузера Apple навколо: він ловить різницю рушіїв, але не все, що специфічне для Safari, яким користуються клієнти.
• Мобільна емуляція — це вʼюпорт, user agent і дотик, а не пристрій. Вона знаходить проблеми верстки й не знайде бага справжнього мобільного браузера.
• Його досяжність закінчується на боці мережі, де браузер. Виклики між серверами й власний годинник сервера належать середовищу, а не тесту.
• Він не тестує нативні десктопні чи мобільні застосунки й не є інструментом навантажувального тестування, хай якою спокусливою виглядає сотня паралельних контекстів.
• Він робить нестабільні тести менш імовірними, але не робить добрим погано обраний набір. Чотириста наскрізних кейсів тут хибні рівно з тих самих причин, що й будь-де.

Антипатерни, які варто назвати

• Явні очікування «про всяк випадок» поверх автоочікування: вони сповільнюють набір і ховають справжнє питання часу.
• Локатори за CSS-класом чи позицією в DOM, бо так записав рекордер: кожен редизайн перетворюється на день ремонту тестів.
• Один контекст на кілька тестів заради часу: так повертається залежність від порядку, яку інструмент і мав прибрати.
• Повтори, які підвищують, доки пайплайн не позеленіє: справжні плаваючі дефекти так стають успішними запусками.
• Незакріплений @playwright/test, тож браузери змінюються в день, який ніхто не обирав.
• Юніт-логіка, перенесена в браузерні тести, бо інструмент приємний, — найдорожчий спосіб бути ретельним.

Коли це застосовувати

Пов’язані сторінки

• QACypressCypress — відкритий раннер тестів для вебзастосунків, що виконує тест усередині браузера, у тій самій вкладці й event loop, що й застосунок. Сторінка починається з дванадцяти маршрутів зі сторінки «Наскрізне тестування» так, як магазин написав би їх на Cypress, — сім нативних, пʼять з обхідним шляхом і те одне, що спільне для всіх пʼяти, — далі вкладка й чотири компроміси, які Cypress називає постійними, черга команд, повторність у тому вигляді, в якому вона працює з Cypress 12, ізоляція й бік Node, паралельність за файлами специфікацій, чотири зміни під робочими наборами і де він не допомагає.
• QASeleniumSelenium — відкритий набір інструментів автоматизації браузера на основі W3C WebDriver, стандарту, який вендори браузерів реалізують у власних драйверах. Сторінка починається з дванадцяти маршрутів зі сторінки «Наскрізне тестування», написаних на Selenium, — хто що забезпечує в кожному, — і з того одного запуску, який до набору магазину може додати лише Selenium: браузери, які клієнти справді встановлюють, включно з Safari на iPhone. Далі протокол і його драйвери, очікування, сесії й доріжка, яку задає один Mac, WebDriver BiDi, grid і його відчинені двері, пʼять змін під робочими наборами і де він не допомагає.
• QAНаскрізне тестування (E2E)Наскрізне тестування проводить бізнес-процес через зібрану систему від початку до кінця, як це зробив би клієнт, в умовах, близьких до продакшну. Сторінка починається з повного набору одного магазину — дванадцять маршрутів, шов, який доводить лише кожен із них, і що в ньому справжнє, а що підмінене, — далі що не доведе жоден нижчий рівень, яких форм набуває набір тестів, чого коштує червоний маршрут, як обирати маршрути й тримати їх надійними, і три збої, де тест зупинився за крок до кінця.