QA Interview Hub · База знань · Тести

Playwright

Архітектура і ізоляція

Архітектура Playwright і ізоляція тестів

Playwright керує браузером ззовні через протоколи: CDP для Chromium і власні патчі для Firefox та WebKit. Тести працюють у Node.js-процесі й надсилають команди браузеру, тому доступні кілька вкладок, вікон, доменів і контекстів в одному тесті. Підтримуються Chromium, Firefox і WebKit, а також мови TypeScript/JavaScript, Python, Java і .NET.

Ключова ієрархія: Browser → BrowserContext → Page. BrowserContext — це ізольована «інкогніто-сесія» зі своїми cookies, storage і кешем, створення якої займає мілісекунди. Тест-раннер за замовчуванням дає кожному тесту новий контекст, тож тести не ділять стан між собою.

Це головна відмінність від Cypress: ізоляція дешева, а паралелізація вбудована і безкоштовна. Тести розподіляються між воркерами — окремими процесами, кожен зі своїм браузером.

Що відбувається під капотом раннера

Коли я запускаю npx playwright test, головний процес збирає список тестів, а потім стартує воркери — окремі Node.js-процеси. Кожен воркер сам імпортує тестові файли, запускає свій браузер і виконує отримані тести. Тому глобальні змінні на рівні модуля не спільні між воркерами: у кожного своя копія.

Важлива деталь, про яку часто не знають: після падіння тесту воркер знищується, і для наступних тестів стартує новий. Це гарантує, що «зламаний» стан не потече в інші тести. Наслідок: beforeAll і worker-фікстури виконаються ще раз у новому воркері. Якщо в beforeAll створюється дорогий тестовий користувач, після кожного падіння він створюватиметься знову.

Так само на нових воркерах ретраї: тест, що впав, перезапускається в новому процесі з чистим браузером.

  • Головний процес: збирає тести, розподіляє, збирає результати для репортерів.
  • Воркер: свій браузер (worker-скоуп), свої фікстури.
  • Тест: свій BrowserContext і Page (test-скоуп).

Звідси правило: не покладатися на порядок тестів і на стан у змінних модуля. Якщо тест A записав щось у змінну, тест B може виконатися в іншому процесі й цього не побачить.

На співбесіді: Раннер розподіляє тести між воркерами — окремими процесами, кожен зі своїм браузером. Після падіння тесту воркер перезапускається, тому beforeAll може виконатися кілька разів. Через це я не тримаю спільний стан у змінних модуля, а все потрібне отримую через фікстури.

Пакети, браузери і канали

Є два пакети: playwright — бібліотека для автоматизації браузера без раннера, і @playwright/test — раннер з фікстурами, асертами, репортерами і паралельністю. Для тестів беруть другий, бібліотеку — для скриптів, скрейпінгу чи інтеграції з іншим раннером.

Браузери не беруться з системи, а завантажуються під конкретну версію Playwright: npx playwright install. У CI на Linux додають системні залежності: npx playwright install --with-deps chromium. Після оновлення пакета браузери треба перевстановити, інакше буде помилка про відсутній executable.

Крім зібраних Chromium, Firefox і WebKit, можна запускати брендовані браузери через channel:

projects: [
  { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
  { name: 'google-chrome', use: { ...devices['Desktop Chrome'], channel: 'chrome' } },
  { name: 'edge', use: { ...devices['Desktop Edge'], channel: 'msedge' } },
],

WebKit у Playwright — це не справжній Safari, а рушій WebKit, близький до нього. Він добре ловить відмінності в рендерингу й поведінці, але фінальну перевірку на реальному iOS-пристрої він не замінює. Це чесна відповідь, яку цінують на співбесіді.

На співбесіді: Для тестів я використовую @playwright/test, а браузери ставлю через npx playwright install --with-deps, бо вони прив'язані до версії пакета. Якщо бізнесу важливий саме Google Chrome чи Edge, додаю проєкти з channel. Також розумію, що WebKit — це наближення до Safari, а не повна заміна реального пристрою.