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, а не повна заміна реального пристрою.