Playwright Interview Guide

Playwright — це open-source фреймворк від Microsoft для end-to-end тестування веб-застосунків у браузері. Підтримує Chromium, Firefox і WebKit в одному API. З'явився у 2020 і швидко став стандартом завдяки простоті і надійності.

Playwright is an open-source framework from Microsoft for end-to-end testing of web apps in a browser. It supports Chromium, Firefox and WebKit behind one API. It appeared in 2020 and became a standard fast, because it is simple and it is reliable.

Головна технічна різниця — спосіб керування браузером:

The main technical difference is how the browser is driven:

Selenium + WebDriver:

Selenium + WebDriver:

WebDriver — це окрема програма-посередник яку кожен виробник браузера пише для свого продукту: ChromeDriver пише Google, GeckoDriver пише Mozilla, SafariDriver вбудований Apple в macOS. Це офіційний стандарт W3C (World Wide Web Consortium — міжнародна організація що розробляє стандарти для вебу). ChromeDriver запускається як окремий процес на твоїй машині і слухає HTTP запити.

WebDriver is a separate middleman program that each browser vendor writes for its own product: ChromeDriver comes from Google, GeckoDriver from Mozilla, SafariDriver is built into macOS by Apple. It is an official W3C standard (World Wide Web Consortium — the international body that writes the standards for the web). ChromeDriver runs as a separate process on your machine and listens for HTTP requests.

Твій тест → HTTP запит → ChromeDriver (окремий процес) → Chrome
                ↑
   кожна дія = окремий запит: відкрити → надіслати → отримати → закрити
   click → запит, fill → запит, screenshot → запит

Your test → HTTP request → ChromeDriver (separate process) → Chrome
                ↑
   each action = separate request: open → send → receive → close
   click → request, fill → request, screenshot → request

Playwright + власні протоколи:

Playwright + its own protocols:

Playwright підключається до браузера напряму через постійне з'єднання — без окремого драйвера-посередника. Для Chromium це CDP (Chrome DevTools Protocol) — той самий протокол що використовують DevTools. Для Firefox і WebKit Playwright використовує власні протоколи, реалізовані в модифікованих збірках браузерів які він поставляє разом із собою. Жодного окремого драйвера — npx playwright install і браузери є.

Playwright connects to the browser directly over a persistent connection — with no separate driver in between. For Chromium that is CDP (Chrome DevTools Protocol), the same protocol DevTools itself uses. For Firefox and WebKit Playwright uses its own protocols, implemented in the patched browser builds it ships with. No separate driver at all — npx playwright install and the browsers are there.

Твій тест → WebSocket → Chromium (CDP)
Твій тест → власний протокол → Firefox (модифікована збірка)
Твій тест → власний протокол → WebKit (модифікована збірка)
                ↑
   одне постійне з'єднання на весь тест
   команди передаються без HTTP WebDriver stack — менше накладних витрат

Your test → WebSocket → Chromium (CDP)
Your test → own protocol → Firefox (patched build)
Your test → own protocol → WebKit (patched build)
                ↑
   one persistent connection for the whole test
   commands go without the HTTP WebDriver stack — less overhead

CDP дає доступ до всіх внутрішніх можливостей браузера — перехоплення мережі, clock, геолокація — бо це той самий канал що й DevTools. WebDriver має тільки ті команди що описані в W3C (World Wide Web Consortium) стандарті.

CDP gives access to everything the browser can do internally — network interception, clock, geolocation — because it is the same channel DevTools uses. WebDriver only has the commands written down in the W3C (World Wide Web Consortium) standard.

Навіщо взагалі WebDriver якщо є CDP?

So why have WebDriver at all if CDP exists?

CDP — це внутрішній протокол Chrome/Chromium. Firefox і Safari його не підтримують нативно. W3C (World Wide Web Consortium) зробили WebDriver офіційним стандартом щоб будь-який інструмент міг керувати будь-яким браузером через один API. Playwright вирішив цю проблему по-своєму — власні модифіковані збірки браузерів з власними протоколами, що дає однаковий API для всіх трьох браузерів.

CDP is an internal Chrome/Chromium protocol. Firefox and Safari do not support it natively. W3C (World Wide Web Consortium) made WebDriver the official standard so that any tool could drive any browser through one API. Playwright solved the same problem its own way — patched browser builds with its own protocols, which gives one identical API across all three browsers.

WebDriver BiDi — варто знати для інтерв'ю: Selenium поступово переходить на WebDriver BiDi (Bidirectional) — новий стандарт W3C який дозволяє двосторонню комунікацію як у CDP. Це наближає Selenium до можливостей Playwright. Але поки що це в процесі розробки.

WebDriver BiDi — worth knowing for the interview: Selenium is gradually moving to WebDriver BiDi (Bidirectional), a new W3C standard that allows two-way communication the way CDP does. It brings Selenium closer to what Playwright can do. But it is still work in progress.

Хто використовує WebDriver сьогодні: Selenium (мільйони корпоративних тестів написані роками), Appium (мобільне тестування Android/iOS), WebdriverIO, і хмарні сервіси BrowserStack та Sauce Labs — їхня інфраструктура побудована на WebDriver стандарті. Це як USB-A: є новіший USB-C — швидший і потужніший — але USB-A досі скрізь бо мільярди пристроїв його підтримують.

Who still uses WebDriver today: Selenium (millions of corporate tests written over the years), Appium (mobile testing on Android/iOS), WebdriverIO, and the cloud services BrowserStack and Sauce Labs — their whole infrastructure is built on the WebDriver standard. It is like USB-A: there is a newer USB-C, faster and more capable, but USB-A is still everywhere because billions of devices speak it.

Практичні переваги Playwright:

Practical advantages of Playwright:

• Auto-waiting — не треба писати явні очікування, Playwright сам чекає поки елемент готовий
• Network interception — вбудований перехват HTTP запитів, можна мокати відповіді
• Ізоляція через BrowserContext — кожен тест в окремому "профілі" без впливу на інші
• Trace Viewer — вбудований запис всіх дій з скріншотами і мережевими запитами для дебагу

• Auto-waiting — no explicit waits to write, Playwright waits until the element is ready by itself
• Network interception — HTTP request interception is built in, responses can be mocked
• Isolation through BrowserContext — every test runs in its own "profile" with no effect on the others
• Trace Viewer — a built-in recording of every action with screenshots and network requests for debugging

Уяви, що Playwright Test ще не існує — є тільки сама бібліотека playwright:

Imagine Playwright Test does not exist yet, and there is only the playwright library itself:

import { chromium } from 'playwright';
const browser = await chromium.launch();
const context = await browser.newContext();
const page = await context.newPage();
await page.goto('https://example.com');

Це не тест — це просто Node.js-програма що відкриває браузер. На цьому рівні Playwright — бібліотека автоматизації браузера, як Express для HTTP чи React для UI. Вона нічого не знає про test(), expect(), beforeEach, retries чи паралельний запуск.

That is not a test — it is just a Node.js program that opens a browser. At this level Playwright is a browser automation library, the way Express is for HTTP or React is for UI. It knows nothing about test(), expect(), beforeEach, retries or parallel runs.

Це і є причина плутанини: у npm справді існують два окремі пакети. playwright — бібліотека автоматизації браузера (Browser, BrowserContext, Page, Locator). @playwright/test — test runner, побудований поверх цієї бібліотеки: додає test(), expect(), fixtures, hooks, workers, retries, projects, reporters. Коли встановлюєш npm init playwright@latest — отримуєш саме @playwright/test, який використовує automation API всередині себе.

And this is where the confusion comes from: there really are two separate packages on npm. playwright is the browser automation library (Browser, BrowserContext, Page, Locator). @playwright/test is the test runner built on top of that library: it adds test(), expect(), fixtures, hooks, workers, retries, projects, reporters. When you run npm init playwright@latest you get @playwright/test, which uses the automation API inside itself.

┌─────────────────────────────┐
│       Playwright Test        │   test(), expect(), fixtures,
│                               │   hooks, workers, retries,
│                               │   projects, reporters
└──────────────┬────────────────┘
               │ використовує
               ▼
┌─────────────────────────────┐
│   Browser Automation API     │   BrowserType, Browser,
│                               │   BrowserContext, Page, Locator
└─────────────────────────────┘

┌─────────────────────────────┐
│       Playwright Test        │   test(), expect(), fixtures,
│                               │   hooks, workers, retries,
│                               │   projects, reporters
└──────────────┬────────────────┘
               │ uses
               ▼
┌─────────────────────────────┐
│   Browser Automation API     │   BrowserType, Browser,
│                               │   BrowserContext, Page, Locator
└─────────────────────────────┘

Що насправді відбувається коли пишеш npx playwright test: спочатку запускається не браузер, а Test Runner — звичайна Node.js-програма. Вона читає playwright.config.ts, знаходить файли з тестами, завантажує їх щоб дізнатись які test(...) там оголошені, розподіляє роботу і тільки після цього створює workers, які вже виконують самі тести. На цьому етапі браузера може ще не існувати взагалі — він з'явиться лише коли якийсь тест реально попросить browser чи page.

What actually happens when you type npx playwright test: the first thing that starts is not a browser but the Test Runner — an ordinary Node.js program. It reads playwright.config.ts, finds the test files, loads them to learn which test(...) calls are declared there, splits up the work, and only then creates the workers that run the tests. At that point a browser may not exist at all — it appears only when some test actually asks for browser or page.

"Завантажує" і "реєструє" — це два різні кроки, які легко сплутати:

"Loads" and "registers" are two different steps, and they are easy to mix up:

• Імпортує — Node.js виконує файл checkout.spec.ts від початку до кінця, як звичайний JS-файл. Усе на верхньому рівні файлу виконується одразу: імпорти, змінні, і кожен виклик test(...).
• Реєструє — відбувається під час імпорту, коли виконання доходить до рядка test('назва', callback). Сам виклик test() НЕ запускає callback (тіло тесту з goto, click) — він лише додає запис у список Test Runner'а: "є тест з такою назвою, ось його код, запусти коли настане час".

• Imports — Node.js executes checkout.spec.ts top to bottom like any other JS file. Everything at the top level runs straight away: imports, variables, and every test(...) call.
• Registers — this happens during that import, the moment execution reaches the line test('name', callback). The test() call itself does NOT run callback (the test body with goto, click) — it only adds an entry to the Test Runner's list: "there is a test with this name, here is its code, run it when the time comes".

Якщо в файлі 5 тестів — під час імпорту всі 5 викликів test(...) виконаються одразу (бо це просто виконання файлу), і всі 5 з'являться у списку зареєстрованих тестів. Але жоден з їхніх callback-ів ще не запустився.

If a file holds 5 tests, then during the import all 5 test(...) calls run at once (because that is simply the file executing) and all 5 land in the list of registered tests. But not one of their callbacks has started yet.

Аналогія: імпорт файлу — це ніби читати зміст книги рецептів сторінка за сторінкою. Кожен test(...) — рядок у змісті: "Рецепт: Паста, дивись стор. 12". Ти вже знаєш що рецепт існує і де його шукати (зареєстрував), але поки що нічого не приготував (не виконав). Тільки після того як усі файли імпортовані й усі тести зареєстровані — Test Runner знає повний список того, що треба виконати, і роздає ці задачі по workers, де вже реально запускаються callback-и.

An analogy: importing a file is like reading the table of contents of a recipe book page by page. Each test(...) is a line in that table of contents: "Recipe: Pasta, see p. 12". You already know the recipe exists and where to find it (you registered it), but you have not cooked anything yet (you have not executed it). Only once every file is imported and every test is registered does the Test Runner know the full list of what has to run, and it hands those out to the workers, where the callbacks finally do execute.

Ключовий інсайт: test('...', callback) нічого не виконує одразу. Він лише реєструє тест у Test Runner — приблизно як runner.addTest(callback). Сам callback запускається пізніше, коли Test Runner вирішить що час його виконувати.

The key insight: test('...', callback) executes nothing at that moment. It only registers the test with the Test Runner — roughly like runner.addTest(callback). The callback itself runs later, when the Test Runner decides it is time.

Worker — не частина браузерного API, його створює Test Runner для розподілу тестів по паралельних Node.js процесах. Вже всередині worker-процесу, коли тест попросить фікстуру browser, вона запускає браузер — і саме тому browser є worker-scoped fixture: один браузерний процес живе всередині одного worker, а не сам по собі.

A worker is not part of the browser API; the Test Runner creates it to spread tests across parallel Node.js processes. Inside that worker process, when a test asks for the browser fixture, the fixture launches a browser — and that is exactly why browser is a worker-scoped fixture: one browser process lives inside one worker, not on its own.

Підсумок двома рівнями: Рівень 1 (Browser Automation API) відповідає на питання "як керувати браузером" — Browser, BrowserContext, Page, Locator. Рівень 2 (Playwright Test) відповідає на питання "як запускати, ізолювати, масштабувати й координувати тести" — test(), fixtures, workers, retries, projects. Тест не керує браузером напряму — він лише описує що треба зробити, а всю координацію бере на себе Test Runner.

The summary, in two levels: Level 1 (the Browser Automation API) answers the question "how do I drive a browser" — Browser, BrowserContext, Page, Locator. Level 2 (Playwright Test) answers "how do I run, isolate, scale and coordinate tests" — test(), fixtures, workers, retries, projects. A test does not drive the browser directly — it only describes what has to happen, and the Test Runner takes on all the coordination.

Node.js — це середовище де може виконуватись JavaScript поза браузером.

Node.js is the environment where JavaScript can run outside a browser.

Спочатку JavaScript існував тільки в браузері — міг маніпулювати DOM, реагувати на кліки, відправляти запити. Але не міг читати файли з диску, запускати сервер, чи взаємодіяти з операційною системою. Node.js змінив це у 2009 — взяв JavaScript рушій з Chrome (V8) і запустив його окремо як самостійну програму на комп'ютері.

At first JavaScript only existed inside the browser — it could manipulate the DOM, react to clicks, send requests. But it could not read files from disk, start a server, or talk to the operating system. Node.js changed that in 2009 — it took the JavaScript engine out of Chrome (V8) and ran it on its own, as a standalone program on your computer.

Тепер JavaScript може робити все що раніше робили тільки серверні мови: читати і писати файли, запускати HTTP сервер, підключатись до бази даних, запускати тести.

Now JavaScript can do everything that used to belong to server languages: read and write files, start an HTTP server, connect to a database, run tests.

WebSocket — це постійне двостороннє з'єднання між двома програмами.

WebSocket is a persistent two-way connection between two programs.

Звичайний HTTP запит: клієнт питає → сервер відповідає → з'єднання закривається. Як SMS — відправив, отримав відповідь, все. WebSocket інакший: з'єднання відкривається один раз і лишається відкритим. Обидві сторони можуть надсилати повідомлення одна одній в будь-який момент. Як телефонна розмова — лінія відкрита, говорять обидва.

A normal HTTP request: the client asks, the server answers, the connection closes. Like a text message — you send it, you get a reply, done. WebSocket is different: the connection opens once and stays open. Either side can send the other a message at any moment. Like a phone call — the line is open and both of you talk.

Як це пов'язано з Playwright: коли ти запускаєш тест — він виконується в Node.js. Playwright відкриває WebSocket з'єднання з браузером один раз на початку і тримає його відкритим весь тест. Через цей канал Node.js надсилає команди браузеру ("клікни тут", "заповни це поле", "виконай цю функцію") і отримує результати назад. Саме тому змінні з Node.js недоступні в браузері — це фізично різні процеси, між ними тільки WebSocket канал.

How this ties back to Playwright: when you run a test, it executes in Node.js. Playwright opens one WebSocket connection to the browser at the start and holds it open for the whole test. Over that channel Node.js sends the browser commands ("click here", "fill this field", "run this function") and gets the results back. That is exactly why variables from Node.js are not available inside the browser — they are physically different processes, and all there is between them is the WebSocket channel.

Щоб зрозуміти WebSocket — спочатку треба зрозуміти як працює звичайний HTTP.

To understand WebSocket you first have to understand how ordinary HTTP works.

HTTP запит — як SMS:

An HTTP request is like a text message:

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

You send a message, the server answers, the connection closes. Every time you need something you send a new request. Each request is a separate connection that opens and closes. Efficient for sites where the data rarely changes — you load the page and there is nothing left to wait for.

WebSocket — як телефонна розмова:

WebSocket is like a phone call:

З'єднання відкривається один раз і лишається відкритим. Обидві сторони можуть надсилати повідомлення одна одній в будь-який момент без нового запиту. Ефективно коли потрібен постійний обмін даними в реальному часі — чати, онлайн-ігри, фінансові тікери, і саме Playwright для керування браузером.

The connection opens once and stays open. Either side can send the other a message at any moment without a new request. Efficient whenever you need a constant exchange of data in real time — chats, online games, financial tickers, and Playwright driving a browser.

Чому Playwright використовує WebSocket: Playwright повинен постійно надсилати команди браузеру і отримувати результати. Якби використовував HTTP — кожна дія (click, fill, evaluate) потребувала б нового з'єднання. WebSocket відкривається один раз і через нього проходять всі команди протягом всього тесту — швидко і ефективно.

Why Playwright uses WebSocket: Playwright has to send the browser commands constantly and get results back. If it used HTTP, every action (click, fill, evaluate) would need a new connection. A WebSocket opens once and carries every command for the whole test — fast and cheap.

Щоб зрозуміти CDP — спочатку треба розділити два рівні які не мають між собою нічого спільного.

To understand CDP you first have to separate two levels that have nothing to do with each other.

Рівень 1 — код аплікейшину (твій React/JS сайт)

Level 1 — the application code (your React/JS site)

Звичайний JavaScript який виконується всередині браузера. Взаємодіє з браузером через вбудовані браузерні API — document, window, fetch. Ніякого CDP тут немає.

Ordinary JavaScript running inside the browser. It talks to the browser through the built-in browser APIs — document, window, fetch. There is no CDP here at all.

Рівень 2 — CDP (Chrome DevTools Protocol)

Level 2 — CDP (Chrome DevTools Protocol)

Канал для зовнішніх програм які хочуть керувати браузером ззовні. Це набір JSON команд які летять через WebSocket між зовнішньою програмою і браузером. CDP — це "розетка" яку Chrome надає зовнішнім програмам. Підключитись може будь-хто хто знає протокол.

A channel for external programs that want to drive the browser from the outside. It is a set of JSON commands flying over a WebSocket between the external program and the browser. CDP is the "socket" Chrome exposes to outside programs. Anyone who knows the protocol can plug into it.

Зовнішня програма (Playwright, DevTools)
        ↓ CDP через WebSocket
   Браузер (Chrome engine)
        ↓ виконує JS
   Код аплікейшину (React, ванільний JS)

External program (Playwright, DevTools)
        ↓ CDP over WebSocket
   Browser (Chrome engine)
        ↓ runs JS
   Application code (React, vanilla JS)

Хто використовує CDP:

Who uses CDP:

• DevTools — коли відкриваєш F12. Це не "вбудована частина Chrome" — це окремий веб-додаток який спілкується з браузером через CDP. Вкладки Elements, Network, Console — все через CDP
• Playwright — керує браузером через CDP: клік, навігація, перехоплення мережі
• Puppeteer — бібліотека від Google, попередник Playwright, теж CDP
• Lighthouse — вимірює performance через CDP
• VS Code debugger — дебагінг Node.js теж через CDP

• DevTools — the thing you open with F12. It is not a "built-in part of Chrome" — it is a separate web app that talks to the browser over CDP. The Elements, Network and Console tabs all go through CDP
• Playwright — drives the browser over CDP: clicks, navigation, network interception
• Puppeteer — Google's library, Playwright's predecessor, also CDP
• Lighthouse — measures performance over CDP
• The VS Code debugger — debugging Node.js goes through CDP too

Аналогія: браузер — це телевізор. Код сайту — відео що грає на екрані. CDP — пульт керування ззовні. DevTools, Playwright, Lighthouse — різні пристрої які підключаються до одного пульта. Самому відео пульт не потрібен — воно просто грає.

An analogy: the browser is a television. The site's code is the video playing on the screen. CDP is the remote control from outside. DevTools, Playwright and Lighthouse are different devices plugging into the same remote. The video itself has no need for a remote — it just plays.

Ми щойно розібрались як Playwright спілкується з браузером через WebSocket і CDP. Тепер подивимось на структуру самого браузера — три рівні ієрархії які пояснюють чому тести ізольовані один від одного навіть при паралельному запуску.

We have just worked out how Playwright talks to the browser over WebSocket and CDP. Now let us look at the structure of the browser itself — the three levels of hierarchy that explain why tests stay isolated from one another even when they run in parallel.

Browser — це сам процес браузера (Chromium, Firefox або WebKit). Дорогий у запуску, тому Playwright тримає один на кожен worker (процес виконання). При паралельному запуску з 4 workers — буде 4 браузерних процеси, по одному на кожен worker.

Browser is the browser process itself (Chromium, Firefox or WebKit). It is expensive to start, so Playwright keeps one per worker (execution process). Run in parallel with 4 workers and you get 4 browser processes, one per worker.

BrowserContext — ізольований "профіль" всередині браузера, схожий на окреме інкогніто вікно. Має свої cookies, localStorage, cache. Playwright створює новий для кожного тесту.

BrowserContext is an isolated "profile" inside the browser, much like a separate incognito window. It has its own cookies, localStorage and cache. Playwright creates a fresh one for every test.

Cookies належать BrowserContext — не Browser і не Page. Кожен context має власний cookie jar: два різні context автоматично мають повністю ізольовані cookies, навіть якщо працюють в одному Browser-процесі. Саме на цьому і побудована ізоляція тестів у Playwright — тест A залогінений під admin ніяк не бачить сесію тесту B. Всі вкладки (Page) всередині одного context — навпаки, cookies спільні.

Cookies belong to the BrowserContext — not to the Browser and not to the Page. Each context has its own cookie jar: two different contexts have completely isolated cookies automatically, even when they run inside the same Browser process. That is exactly what test isolation in Playwright is built on — test A, logged in as admin, cannot see test B's session. All the tabs (Pages) inside one context, by contrast, share cookies.

Page — одна вкладка всередині context. Саме з нею ти взаємодієш через goto, click, fill.

Page is a single tab inside a context. It is the thing you actually interact with through goto, click, fill.

Коли ти пишеш async ({ page }) в тесті — ти не створюєш вкладку вручну. Playwright сам підготував Browser, створив новий BrowserContext і відкрив у ньому Page — і передав тобі готову. Це і є fixture: готовий ресурс який фреймворк підготував за тебе. Детальніше про fixtures — в наступних двох картках.

When you write async ({ page }) in a test you are not creating the tab by hand. Playwright has already prepared a Browser, created a new BrowserContext and opened a Page inside it — and handed it to you ready to use. That is what a fixture is: a resource the framework prepared on your behalf. More on fixtures in the next two cards.

Фікстура — це готовий ресурс який Playwright сам підготував і передав у тест. Ти просто називаєш що тобі потрібно — і отримуєш це готовим. Після тесту Playwright сам прибирає.

A fixture is a ready-made resource that Playwright prepared and handed into the test. You simply name what you need and you get it, ready. After the test Playwright cleans up on its own.

Аналогія з рестораном: ти не ходиш на кухню щоб взяти тарілку — офіціант приносить її сам. Ти просто замовляєш "мені потрібна тарілка" і отримуєш готову. Fixture — це той офіціант.

A restaurant analogy: you do not walk into the kitchen to fetch a plate — the waiter brings it. You just order, "I need a plate", and get one ready. A fixture is that waiter.

У коді це виглядає так: коли пишеш async ({ page }) — ти не створюєш page сам. Playwright читає ключ деструктуризації page, розуміє що тобі потрібна вкладка, і підставляє готову. Важливо: Playwright дивиться на ключ об'єкта, а не на ім'я локальної змінної. Тому async ({ page: myPage }) працює так само — fixture key залишається page, просто локальна змінна перейменована на myPage.

In code it looks like this: when you write async ({ page }) you are not creating page yourself. Playwright reads the destructuring key page, works out that you need a tab, and passes one in ready. One detail matters: Playwright looks at the object key, not at the name of your local variable. So async ({ page: myPage }) works exactly the same — the fixture key is still page, the local variable is simply renamed to myPage.

Це схоже на Dependency Injection (DI) — патерн з бекенд-розробки. DI означає: "не створюй залежності сам — отримай їх ззовні". Замість того щоб писати new Database() всередині класу — клас отримує вже готовий об'єкт бази даних через конструктор або параметр. Так само тест отримує готову page через параметр функції — не сам її створює.

This is close to Dependency Injection (DI), a pattern from backend development. DI means: "do not create your dependencies yourself — receive them from outside". Instead of writing new Database() inside a class, the class receives a ready database object through its constructor or a parameter. In the same way a test receives a ready page through a function parameter instead of creating it.

Ми вже знаємо що таке Node.js, WebSocket, ієрархія браузера і fixtures. Час написати перший реальний тест — і ти побачиш як всі ці концепти з'єднуються разом.

We already know what Node.js is, what a WebSocket is, the browser hierarchy and fixtures. Time to write the first real test — and you will see how all those concepts click together.

Базовий тест складається з трьох частин: імпорт test і expect з Playwright, оголошення тесту через функцію test() з назвою і async функцією, і деструктуризація fixtures { page } — саме тут ми "просимо" Playwright дати нам готову вкладку.

A basic test has three parts: the import of test and expect from Playwright, the test declaration through the test() function with a name and an async function, and the fixture destructuring { page } — that is where we "ask" Playwright for a ready tab.

Зверни увагу на await перед кожною дією — Playwright асинхронний, і без await наступний рядок виконається не чекаючи завершення попереднього.

Notice the await in front of every action — Playwright is asynchronous, and without await the next line runs without waiting for the previous one to finish.

Callback — це функція яку ти передаєш іншій функції, але сама не викликаєш. Той хто отримав твою функцію — вирішує коли її викликати.

A callback is a function you hand to another function without calling it yourself. Whoever received your function decides when to call it.

Подивимось на конкретний приклад з Playwright:

Let us look at a concrete Playwright example:

await page.route('**/api/**', route => {
  route.fulfill({ status: 200 });
});

Тут є дві функції: page.route() — це метод Playwright, він знає як слідкувати за мережевими запитами. І route => { ... } — це твоя функція. Ти її написала, але сама не викликаєш.

There are two functions here: page.route() is a Playwright method that knows how to watch network requests. And route => { ... } is your function. You wrote it, but you never call it.

Ти даєш свою функцію Playwright і кажеш: "ось моя функція, ти знаєш коли її викликати — викликай коли буде запит". Playwright тримає твою функцію у себе. Коли браузер робить запит на /api/ — Playwright сам викличе твою функцію і передасть в неї об'єкт route.

You give your function to Playwright and say: "here is my function, you know when to call it — call it when a request comes in". Playwright keeps your function. When the browser makes a request to /api/, Playwright calls your function itself and passes the route object into it.

Тобто: ти — пишеш функцію і передаєш її. Playwright — вирішує коли її викликати і викликає.

So: you write the function and hand it over. Playwright decides when to call it, and calls it.

Ще простіший приклад — setTimeout:

An even simpler example — setTimeout:

setTimeout(() => {
  console.log('привіт');
}, 3000);
// () => { console.log('привіт') } — це callback
// Ти передала її setTimeout
// setTimeout чекає 3 секунди і сам викликає твою функцію
// Ти не викликала її — він викликав

setTimeout(() => {
  console.log('hello');
}, 3000);
// () => { console.log('hello') } — this is a callback
// You passed it to setTimeout
// setTimeout waits 3 seconds and calls your function itself
// You didn't call it — it did

Callback зустрічається скрізь у Playwright:

Callbacks turn up everywhere in Playwright:

// page.on() — Playwright викличе твій callback коли відбудеться подія
page.on('dialog', dialog => {
  dialog.accept(); // ← твій callback, Playwright викликає коли з'явиться діалог
});

// forEach — JavaScript викличе твій callback для кожного елемента
[1, 2, 3].forEach(num => {
  console.log(num); // ← твій callback, forEach викликає тричі
});

// test() — Playwright викличе твій callback коли запускає тест
test('назва тесту', async ({ page }) => {
  // ← це теж callback! Playwright викликає його коли запускає тест
});

// page.on() — Playwright calls your callback when the event happens
page.on('dialog', dialog => {
  dialog.accept(); // ← your callback, Playwright calls it when a dialog appears
});

// forEach — JavaScript calls your callback for each element
[1, 2, 3].forEach(num => {
  console.log(num); // ← your callback, forEach calls it three times
});

// test() — Playwright calls your callback when it runs the test
test('test name', async ({ page }) => {
  // ← this is a callback too! Playwright calls it when it runs the test
});

💡 Як розпізнати callback в коді: бачиш що функція передається як аргумент (всередині дужок іншої функції) і ти її не викликаєш одразу — це callback. Стрілочна функція () => {} або async () => {} як аргумент — майже завжди callback.

💡 How to spot a callback in code: you see a function passed as an argument (inside another function's parentheses) and you are not calling it right there — that is a callback. An arrow function () => {} or async () => {} as an argument is almost always a callback.

Чому без () після callback — важливо:

Why leaving the () off a callback matters:

const greet = () => console.log('привіт');

// З дужками () — викликаємо ЗАРАЗ і передаємо результат
setTimeout(greet(), 1000);
// greet() виконалась одразу при читанні цього рядка
// setTimeout отримав undefined — бо greet нічого не повертає

// Без дужок — передаємо саму функцію
setTimeout(greet, 1000);
// setTimeout тримає greet у себе і викличе через 1000мс

const greet = () => console.log('hello');

// With parentheses () — call it NOW and pass the result
setTimeout(greet(), 1000);
// greet() ran immediately when this line was evaluated
// setTimeout got undefined — because greet returns nothing

// Without parentheses — pass the function itself
setTimeout(greet, 1000);
// setTimeout holds on to greet and calls it after 1000ms

Аналогія: ти даєш другу завдання "зателефонуй мамі через годину". greet — це номер телефону. Друг сам натисне дзвінок через годину. greet() — це ти сама набрала номер і дала другу вже активний дзвінок. Мама вже відповідає — до того як минула година.

An analogy: you ask a friend to "ring mum in an hour". greet is the phone number. Your friend presses dial an hour later. greet() is you dialling the number yourself and handing your friend a live call. Mum is already answering — before the hour is up.

Як знайти callback у складному коді — три кроки:

How to find the callback in complicated code — three steps:

1. Знайди виклик функції — відкриваючу дужку (
2. Шукай всередині дужок => або ключове слово function
3. Все що після => до відповідної закриваючої ) — це callback і його тіло

1. Find the function call — the opening parenthesis (
2. Look inside the parentheses for => or the keyword function
3. Everything from => to the matching closing ) is the callback and its body

Твій тест і браузер — це два окремі процеси. Тест виконується в Node.js, браузер (Chromium/Firefox/WebKit) — окрема програма зі своєю пам'яттю. Вони спілкуються через протокол обміну повідомленнями — у Chromium це CDP (Chrome DevTools Protocol) поверх WebSocket, той самий протокол, яким користується сама вкладка DevTools.

Your test and the browser are two separate processes. The test runs in Node.js; the browser (Chromium/Firefox/WebKit) is a separate program with its own memory. They talk over a message protocol — in Chromium that is CDP (Chrome DevTools Protocol) on top of a WebSocket, the same protocol the DevTools tab itself uses.

Кожна команда, яку Playwright шле браузеру — click, goto, textContent — це JSON-повідомлення з унікальним id. CDP побудований на JSON-RPC: "every command sent by the client must have a unique id... responses from Chromium carry the same id". Браузер, відповідаючи, включає той самий id, щоб Playwright міг зіставити відповідь із запитом навіть коли кілька команд летять одночасно.

Every command Playwright sends the browser — click, goto, textContent — is a JSON message with a unique id. CDP is built on JSON-RPC: "every command sent by the client must have a unique id... responses from Chromium carry the same id". When the browser answers it includes that same id, so Playwright can match a response to its request even when several commands are in flight at once.

Звідси й наслідок: жодна дія, що взаємодіє з браузером, не може виконатись миттєво в тому ж рядку коду — вона мусить дочекатись відповіді. Тому майже всі методи, які взаємодіють із браузером, повертають Promise (не буквально всі — page.locator(), getByRole(), browser.contexts() синхронні, бо нічого не питають у браузера в момент виклику).

Which leads straight to this: no action that touches the browser can finish instantly on the same line of code — it has to wait for the answer. That is why almost every method that talks to the browser returns a Promise (not literally every one — page.locator(), getByRole() and browser.contexts() are synchronous, because they ask the browser nothing at the moment you call them).

await — не окрема команда "почекай". Спрощено це можна уявити як синтаксис, що бере весь код нижче і "прикріплює" його як callback до Promise через .then():

await is not a separate "wait here" command. Simplified, you can picture it as syntax that takes all the code below it and "attaches" it as a callback to the Promise through .then():

Де саме проходить межа callback: до найближчого наступного await, а якщо його немає — до кінця функції. Не буквально "наступний рядок" — між двома await може бути кілька синхронних рядків (console.log, обчислення), і всі вони потрапляють в один і той самий callback:

Where exactly the callback boundary runs: to the nearest following await, and if there is none — to the end of the function. Not literally "the next line": there can be several synchronous lines between two awaits (console.log, calculations), and all of them end up in one and the same callback:

Саме тому в першому прикладі waitFor() опинився всередині callback1: між першим і другим await не було жодного проміжного рядка, тож callback1 склався виключно з виклику waitFor() — межа шукала наступний await, знайшла його одразу, і більше нічого туди не потрапило.

That is why in the first example waitFor() ended up inside callback1: there was not a single line between the first and the second await, so callback1 consisted of nothing but the waitFor() call — the boundary went looking for the next await, found it immediately, and nothing else made it in.

Callback — не окрема пауза "подумати". Це просто "шматок коду, викликаний пізніше". Що саме він робить, коли його викликають — залежить від того, чи є що передавати:

A callback is not a separate pause to "think". It is simply "a chunk of code called later". What it does when it is called depends on whether there is anything to pass along:

• Є значення для передачі — const price = await locator.textContent(). Callback отримує реальний текст і кладе його в змінну.
• Нема що передавати — await click(); await waitFor();. click() не повертає нічого змістовного, тому callback1 просто запускає наступну дію, нічого не "отримуючи" з попередньої.

• There is a value to pass — const price = await locator.textContent(). The callback receives the actual text and puts it into the variable.
• There is nothing to pass — await click(); await waitFor();. click() returns nothing meaningful, so callback1 simply starts the next action without "receiving" anything from the previous one.

(Для простоти поки що вважатимемо, що черга одна. У наступній картці побачимо, що насправді їх дві.)

(For simplicity we will assume for now that there is one queue. In the next card we will see there are actually two.)

Event loop — не частина V8. Це поширена помилка. Event loop у Node.js реалізований бібліотекою libuv (C-бібліотека для асинхронного I/O), не самим JS-рушієм. V8 відповідає за виконання JavaScript, тримає call stack і обробляє microtask queue (продовження після await, .then()). Libuv координує коли передати керування назад у V8, забираючи готові задачі з черги.

The event loop is not part of V8. This is a common mistake. In Node.js the event loop is implemented by libuv (a C library for asynchronous I/O), not by the JS engine. V8 is responsible for executing JavaScript, holds the call stack and handles the microtask queue (continuations after await and .then()). Libuv coordinates when control goes back into V8, taking ready tasks off the queue.

Дійові особи, і де саме вони живуть:

The cast, and where each of them lives:

• Call Stack — належить V8 (JS-рушію). Node.js використовує цей стек для виконання твого тестового коду.
• Черга — тут з'являється продовження, коли приходить відповідь від браузера.
• Браузер — окремий процес зі своїм власним call stack, який тебе як тестувальницю не стосується.
• Event loop (у libuv) — координує, коли готова задача з черги передається назад у V8 на виконання.

• Call Stack — belongs to V8 (the JS engine). Node.js uses that stack to run your test code.
• The queue — where the continuation shows up when the answer from the browser arrives.
• The browser — a separate process with its own call stack, which is none of your business as a tester.
• The event loop (in libuv) — coordinates when a ready task from the queue is handed back to V8 to run.

Покроково, на прикладі await click(); await waitFor();:

Step by step, on the example await click(); await waitFor();:

Чому callback не летить напряму на стек, а спочатку в чергу: JS виконує лише одну функцію за раз. Якби готовий код клався одразу на стек — він міг би влізти посеред того, що вже там виконується, і перервати на середині. Черга — буфер ввічливості: новий код чекає, поки стек не звільниться сам, і тільки тоді event loop його забирає.

Why the callback does not fly straight onto the stack but goes into the queue first: JS runs exactly one function at a time. If ready code were put straight onto the stack it could barge into the middle of whatever is already running there and cut it in half. The queue is a politeness buffer: new code waits until the stack clears on its own, and only then does the event loop pick it up.

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

In the previous card we pretended for simplicity that there is one queue. There are actually two. The question is not how they differ. The question is why one turned out not to be enough.

Перше питання, яке виникає майже в усіх: чому Promise виконався раніше за setTimeout(0)? Адже таймер теж уже готовий.

The first question almost everybody asks: why did the Promise run before setTimeout(0)? The timer was ready too.

💡 JavaScript розділяє задачі не за швидкістю, а за роллю.

💡 JavaScript splits tasks by role, not by speed.

Продовження вже розпочатої роботи. У більшості коду, який ми пишемо (і практично у всьому Playwright), microtask використовується саме для продовження вже розпочатої асинхронної операції:

Continuing work that has already started. In most of the code we write (and in practically all of Playwright) a microtask is exactly that — the continuation of an asynchronous operation that already began:

console.log(text) не нова задача, а продовження тієї самої функції після завершення textContent(). Саме тому це microtask.

console.log(text) is not a new task, it is the continuation of the same function after textContent() finished. That is precisely why it is a microtask.

Macrotask — починає нову незалежну роботу. setTimeout(() => console.log('cleanup'), 0) — колбек таймера не продовжує жоден await. Це окреме прохання: "коли буде можливість — виконай ще й це".

A macrotask starts new, independent work. setTimeout(() => console.log('cleanup'), 0) — the timer's callback continues no await. It is a separate request: "when you get a chance, run this as well".

Саме через цю різницю ролей JavaScript завжди спершу закінчує весь поточний ланцюжок виконання (усі microtasks), і лише потім переходить до наступної незалежної задачі (macrotask).

It is this difference in role that makes JavaScript always finish the whole current chain of execution (every microtask) first, and only then move on to the next independent task (a macrotask).

💡 Не варто запам'ятовувати: "microtasks виконуються раніше". Краще запам'ятати причину: JavaScript спочатку завершує вже розпочату роботу, і лише потім починає нову.

💡 Not worth memorising: "microtasks run first". Better to remember the reason: JavaScript finishes the work it has already started before it begins anything new.

А хто всім цим керує? Відповідальність тут теж поділена: V8 відповідає за виконання JavaScript і microtasks, libuv відповідає за event loop і macrotasks.

And who runs all of this? The responsibility is split here too: V8 is responsible for executing JavaScript and microtasks, libuv is responsible for the event loop and macrotasks.

• Microtask queue обробляє V8. Сюди потрапляє продовження після кожного await і кожного .then(). Оскільки майже всі дії Playwright (click, goto, fill, textContent) завершуються через Promise, їх продовження теж опиняється саме тут.
• Macrotask queue координує event loop (libuv). Тут живуть setTimeout, setInterval. page.waitForTimeout() зрештою використовує цей самий механізм таймерів.

• The microtask queue is handled by V8. This is where the continuation after every await and every .then() lands. Since nearly every Playwright action (click, goto, fill, textContent) finishes through a Promise, their continuations end up here as well.
• The macrotask queue is coordinated by the event loop (libuv). This is where setTimeout and setInterval live. page.waitForTimeout() ends up using that same timer machinery.

(Технічна виноска: є рідкісний випадок queueMicrotask(), який дозволяє явно поставити в microtask queue будь-яку функцію, навіть таку, що нічого не "продовжує" — у 99% Playwright-коду це не зустрічається, тому основне правило вище тримається.)

(A technical footnote: there is the rare case of queueMicrotask(), which lets you put any function into the microtask queue explicitly, even one that "continues" nothing — in 99% of Playwright code you will not meet it, so the rule above holds.)

Оскільки виклик асинхронної функції завжди синхронний і миттєвий (відправляє команду і одразу звільняє стек) — можна відправити кілька незалежних запитів одночасно, замість того щоб чекати кожен по черзі:

Because calling an async function is always synchronous and instant (it sends the command and frees the stack right away), you can fire several independent requests at once instead of waiting for each one in turn:

⚠️ Але НЕ клади кілька дій (не читання, а саме дій) в один Promise.all(). Playwright гарантує стабільність окремої дії через auto-waiting; якщо запустити дві дії одночасно на одній Page, вони можуть почати конкурувати за фокус, DOM або навігацію — це поводиться як кілька людей, що одночасно керують однією клавіатурою.

⚠️ But do NOT put several actions (not reads — actual actions) into one Promise.all(). Playwright guarantees the stability of a single action through auto-waiting; start two actions at once on the same Page and they can end up competing for focus, the DOM or navigation — it behaves like several people driving one keyboard.

1. Об'єкт в JavaScript живе в оперативній пам'яті конкретного процесу як структура з адресами — { name → адреса 0x7f4b → 'Iuliia' }. Ці адреси мають сенс тільки всередині цього одного процесу.
2. Мережа і файли передають байти. Якщо відправити адресу 0x7f4b — на іншому комп'ютері вона вкаже на іншу ділянку пам'яті або нікуди. Об'єкт прив'язаний до конкретної пам'яті процесу.
3. Серіалізація — перетворення об'єкта з "адрес в пам'яті" в текст де значення записані явно. Текст не залежить від конкретної машини.
4. Десеріалізація — зворотній процес: текст назад в об'єкт.
5. JSON — найпоширеніший формат серіалізації у вебі. Виглядає майже як JavaScript об'єкт, розуміє будь-яка мова програмування і будь-який сервер.
6. У Playwright серіалізація відбувається коли передаємо аргументи в evaluate() або waitForFunction() — Playwright перетворює JavaScript об'єкт в JSON, відправляє через WebSocket в браузер, браузер десеріалізує назад в об'єкт.

1. A JavaScript object lives in the memory of one specific process as a structure of addresses — { name → address 0x7f4b → 'Iuliia' }. Those addresses only mean anything inside that one process.
2. Networks and files carry bytes. Send the address 0x7f4b and on another machine it points at a different chunk of memory, or at nothing. The object is tied to one process's memory.
3. Serialisation is turning an object from "addresses in memory" into text where the values are written out explicitly. Text does not depend on a particular machine.
4. Deserialisation is the way back: text into an object again.
5. JSON is the most common serialisation format on the web. It looks almost like a JavaScript object, and every programming language and every server understands it.
6. In Playwright, serialisation happens when we pass arguments into evaluate() or waitForFunction() — Playwright turns the JavaScript object into JSON, sends it over the WebSocket to the browser, and the browser deserialises it back into an object.

Аналогія: об'єкт — це будинок у твоєму місті. Ти не можеш "відправити будинок" другу в іншому місті. Але можеш зробити план будинку і відправити його — це і є серіалізація. Друг отримує план і будує такий самий будинок — це десеріалізація.

An analogy: an object is a house in your town. You cannot "send a house" to a friend in another town. But you can draw its plans and send those — that is serialisation. Your friend receives the plans and builds the same house — that is deserialisation.

Spread оператор ... — це "розгорни і вистав вміст". Він бере масив або об'єкт і вставляє всі його елементи або поля в нове місце.

The spread operator ... means "unwrap this and lay out the contents". It takes an array or an object and inserts all of its elements or fields somewhere new.

В JavaScript є два типи методів — ті що викликаються на екземплярі класу, і ті що викликаються на самому класі. Другі називаються статичними.

JavaScript has two kinds of methods — the ones you call on an instance of a class, and the ones you call on the class itself. The second kind are called static.

Звичайний метод — спочатку створюєш об'єкт через new, потім викликаєш метод на ньому:

A regular method — first you create an object with new, then you call the method on it:

const arr = new Array();  // створили екземпляр
arr.push(1);               // викликаємо метод на екземплярі

const str = new String('hello');
str.toUpperCase();          // метод екземпляру

const arr = new Array();  // created an instance
arr.push(1);               // call a method on the instance

const str = new String('hello');
str.toUpperCase();          // instance method

Статичний метод — викликається прямо на класі, без створення екземпляру:

A static method — called straight on the class, with no instance created:

// Не треба: const j = new JSON(); j.stringify()
JSON.stringify(obj);     // статичний — викликаємо на класі JSON
JSON.parse(text);        // статичний

Math.random();           // статичний — не треба new Math()
Math.max(1, 2, 3);       // статичний

Array.isArray([]);       // статичний — перевіряє чи це масив

Promise.all([p1, p2]);   // статичний — виконує кілька Promise паралельно

// В Playwright:
expect.poll(async () => {}); // poll — статичний метод на expect
expect.extend({});          // extend — теж статичний

// Not needed: const j = new JSON(); j.stringify()
JSON.stringify(obj);     // static — called on the JSON class
JSON.parse(text);        // static

Math.random();           // static — no need for new Math()
Math.max(1, 2, 3);       // static

Array.isArray([]);       // static — checks whether it's an array

Promise.all([p1, p2]);   // static — runs several Promises in parallel

// In Playwright:
expect.poll(async () => {}); // poll — a static method on expect
expect.extend({});          // extend — also static

Як визначити статичний метод у своєму класі:

How to define a static method in your own class:

class MathHelper {
  // Статичний метод — ключове слово static
  static double(n: number) {
    return n * 2;
  }

  // Звичайний метод
  add(n: number) {
    return n + 1;
  }
}

// Статичний — на класі:
MathHelper.double(5); // ✅ 10

// Звичайний — на екземплярі:
const m = new MathHelper();
m.add(5); // ✅ 6

class MathHelper {
  // Static method — the static keyword
  static double(n: number) {
    return n * 2;
  }

  // Regular method
  add(n: number) {
    return n + 1;
  }
}

// Static — on the class:
MathHelper.double(5); // ✅ 10

// Regular — on the instance:
const m = new MathHelper();
m.add(5); // ✅ 6

Простіше запам'ятати: якщо перед методом в коді бачиш назву класу з великої літери — це статичний: JSON.stringify, Math.random, Promise.all, Array.isArray, expect.poll. Якщо перед методом змінна — це екземпляр: arr.push, str.toUpperCase.

An easier way to remember it: if what stands in front of the method is a capitalised class name, it is static: JSON.stringify, Math.random, Promise.all, Array.isArray, expect.poll. If it is a variable, it is an instance method: arr.push, str.toUpperCase.

try/catch — це спосіб обробити помилку не дозволяючи їй зупинити програму. Коли код всередині try кидає помилку — виконання переходить в catch, а не зупиняється повністю.

try/catch is a way to handle an error without letting it stop the program. When the code inside try throws, execution moves into catch instead of stopping altogether.

Локатор — це спосіб знайти елемент на сторінці. Це не сам елемент, а інструкція "знайди мені ось це". Playwright шукає елемент заново кожного разу коли ти виконуєш дію — клік, fill, перевірку.

A locator is a way to find an element on the page. It is not the element itself, it is the instruction "go find me this one". Playwright looks the element up again every single time you perform an action — a click, a fill, a check.

Playwright рекомендує семантичні локатори — ті що шукають елемент за його змістом і роллю, а не за CSS класом або позицією в DOM. Чому? Бо CSS класи часто змінюються при рефакторингу, а роль кнопки "Submit" — ні.

Playwright recommends semantic locators — the ones that find an element by its meaning and role rather than by a CSS class or a position in the DOM. Why? Because CSS classes change all the time during a refactor, and the role of a "Submit" button does not.

Коли локатор знаходить більше одного елемента і ти намагаєшся виконати дію — Playwright навмисно падає з помилкою. Це і є strict mode.

When a locator matches more than one element and you try to act on it, Playwright fails on purpose. That is strict mode.

У Selenium є метод findElement — він мовчки бере перший елемент зі списку якщо знайшов кілька. Здається зручно — але це джерело прихованих багів: тест "зелений", але клікає не на ту кнопку яку ти мав на увазі.

Selenium has findElement — it silently takes the first element it found if there were several. That looks convenient, but it is a source of hidden bugs: the test is "green" while it clicks a different button than the one you meant.

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

Playwright went the other way: an explicit failure now beats a quiet bug later. If a locator matched several elements, that is a signal the locator is not specific enough. Make it specific.

Де саме діє strict mode: це властивість Locator API. Всі дії (click, fill) і web-first assertions на локаторі вимагають щоб він резолвився рівно в один елемент — інакше помилка strict mode violation. Виняток — методи які працюють зі списком за задумом: count(), all(), toHaveCount(). Старе ElementHandle API (page.$()) під strict mode не підпадає — воно мовчки бере перший елемент, як Selenium. Це ще одна причина не використовувати його.

Where strict mode actually applies: it is a property of the Locator API. Every action (click, fill) and every web-first assertion on a locator requires it to resolve to exactly one element — otherwise you get a strict mode violation. The exception is the methods that work with a list by design: count(), all(), toHaveCount(). The old ElementHandle API (page.$()) is not covered by strict mode at all — it silently takes the first element, like Selenium. One more reason not to use it.

⚠️ Про nth() і first(): це не універсальне рішення для strict mode violation, а часто спосіб заглушити симптом. Використовуй nth() тільки коли порядок реально є частиною бізнес-логіки ("перший товар у списку рекомендацій", "третій крок чекауту"). Якщо ти пишеш nth(2) просто щоб тест перестав падати — локатор поламається від першої ж зміни верстки. Краще знайти стабільніший спосіб: filter({ hasText }), getByRole з назвою, або getByTestId.

⚠️ About nth() and first(): these are not the universal answer to a strict mode violation, they are often a way to mute the symptom. Use nth() only when the order really is part of the business logic ("the first item in the recommendations", "the third step of checkout"). If you write nth(2) just to stop the test failing, the locator will break on the very next markup change. Find something more stable instead: filter({ hasText }), getByRole with a name, or getByTestId.

Перед кожною взаємодією з елементом Playwright виконує так звані Actionability Checks — набір перевірок що елемент готовий до дії. Для більшості дій це: елемент є в DOM (attached), видимий (visible), не анімується (stable), активний (enabled). Для fill() додатково — доступний для редагування (editable), для кліку — може отримувати події (receives events, тобто не перекритий іншим елементом). Timeout за замовчуванням — 30 секунд. Це означає що більшість часу не треба писати жодних явних очікувань — просто клікаєш і Playwright сам розбереться.

Before every interaction with an element Playwright runs what it calls actionability checks — a set of checks that the element is ready to be acted on. For most actions that means: the element is in the DOM (attached), visible (visible), not animating (stable), and enabled (enabled). For fill() there is one more — editable (editable); for a click — it can receive events (receives events, i.e. nothing is covering it). The default timeout is 30 seconds. Which means most of the time you write no explicit waits at all — you click, and Playwright sorts it out.

Але є ситуації коли waitFor() потрібен явно:But there are situations where you do need waitFor() explicitly:

• Чекаємо зміну URL — після кліку відбувається навігація на іншу сторінку
• Waiting for a URL change — the click navigates to a different page
• Чекаємо стан завантаження — коли важливо що всі запити завершились
• Waiting for a load state — when it matters that every request has finished
• Чекаємо появу або зникнення елемента явно — коли елемент не є ціллю дії, а просто індикатором стану (наприклад toast-повідомлення)
• Waiting for an element to appear or disappear explicitly — when the element is not the target of the action but a state indicator (a toast message, say)
• Чекаємо довільну JS умову — через waitForFunction() коли немає DOM-елемента для перевірки
• Waiting for an arbitrary JS condition — via waitForFunction(), when there is no DOM element to check against

⚠️ { force: true } — майже завжди антипатерн. Він вимикає Actionability Checks: Playwright більше не перевіряє чи елемент видимий, чи не перекритий, чи взагалі готовий — просто б'є подією по координатах. Це не "пришвидшення тесту", а вимкнення захисту.

Якщо force: true "полагодив" тест — значить тест тепер проходить попри реальну проблему: елемент перекритий модалкою, кнопка ще disabled, оверлей не зник. Юзер у такій ситуації клікнути б не зміг — а тест каже "все ок".

Виправдані випадки рідкісні: навмисна перевірка кліку по частково перекритому елементу, або обхід відомого бага стороннього віджета. І тоді поруч має бути коментар чому.

⚠️ { force: true } is almost always an anti-pattern. It turns the actionability checks off: Playwright stops checking whether the element is visible, whether something covers it, whether it is ready at all — it just fires an event at the coordinates. That is not "making the test faster", it is switching the safety net off.

If force: true "fixed" a test, the test now passes despite a real problem: the element is covered by a modal, the button is still disabled, an overlay never went away. A user in that situation could not have clicked — and the test says everything is fine.

The legitimate cases are rare: deliberately testing a click on a partially covered element, or working around a known bug in a third-party widget. And then there should be a comment next to it saying why.

page.waitForTimeout(3000) — це фіксована пауза: тест зупиняється рівно на 3 секунди незалежно від того чи UI вже готовий чи ні. Це антипатерн з трьох причин: якщо UI готовий за 0.5 секунди — ти витрачаєш зайві 2.5 секунди; якщо UI не готовий за 3 секунди — тест впаде; і тести стають повільними і крихкими одночасно.

page.waitForTimeout(3000) is a fixed pause: the test stops for exactly 3 seconds whether the UI is ready or not. It is an anti-pattern for three reasons: if the UI is ready in half a second you burn 2.5 seconds for nothing; if it is not ready in 3 seconds the test fails; and the tests get slow and flaky at the same time.

Playwright має auto-waiting — він сам чекає поки елемент готовий до взаємодії. Тому майже завжди замість waitForTimeout є правильніша альтернатива.

Playwright has auto-waiting — it waits for the element to be ready to interact with on its own. So almost every time, there is a better alternative to waitForTimeout.

waitForLoadState('networkidle') — стан що означає "немає жодного мережевого запиту 500 мілісекунд". Здається зручним способом дочекатись поки "все завантажилось". Але на практиці це частий антипатерн.

waitForLoadState('networkidle') is a state that means "no network request for 500 milliseconds". It looks like a handy way to wait until "everything has loaded". In practice it is a common anti-pattern.

Проблема: сучасні сайти мають постійний фоновий трафік — аналітика надсилає дані, WebSocket тримає з'єднання, polling оновлює дані. Стан "тиші 500мс" може ніколи не настати — і тест зависне до таймауту.

The problem: modern sites have constant background traffic — analytics posting data, a WebSocket holding a connection open, polling refreshing data. That "500ms of quiet" may never arrive — and the test hangs until it times out.

Більшість людей думають що в Playwright є один таймаут. Насправді їх три, і вони незалежні один від одного. Класична ситуація: ти поставила timeout: 60000 в конфізі і все одно тест падає через 5 секунд — і не розумієш чому. Відповідь: ти поміняла не той таймаут.

Most people think Playwright has one timeout. It actually has three, and they are independent of each other. The classic situation: you set timeout: 60000 in the config and the test still fails after 5 seconds — and you cannot see why. The answer: you changed the wrong timeout.

• Test timeout — скільки часу має весь тест від першого до останнього рядка. Якщо тест не завершився за цей час — Playwright його вбиває. За замовчуванням 30 секунд.
• Test timeout — how long the whole test gets, from the first line to the last. If the test has not finished by then, Playwright kills it. 30 seconds by default.
• Action timeout — скільки Playwright чекає поки окрема дія виконається: click(), fill(), hover(). Це той самий auto-waiting. За замовчуванням немає окремого обмеження (наслідує test timeout), але можна встановити явно через use: { actionTimeout }.
• Action timeout — how long Playwright waits for a single action to go through: click(), fill(), hover(). This is the auto-waiting one. By default there is no separate limit (it inherits the test timeout), but you can set it explicitly through use: { actionTimeout }.
• Expect timeout — скільки web-first assertion ретраїться перш ніж здатись. expect(locator).toBeVisible() перевіряє умову знову і знову. За замовчуванням 5 секунд.
• Expect timeout — how long a web-first assertion retries before giving up. expect(locator).toBeVisible() re-checks the condition over and over. 5 seconds by default.
• Navigation timeout — окремий таймаут для goto(), waitForURL(), waitForNavigation(). Встановлюється через use: { navigationTimeout }. Часто пропускають — а саме він винен коли goto() падає на повільному стейджі.
• Navigation timeout — a separate timeout for goto(), waitForURL(), waitForNavigation(). Set through use: { navigationTimeout }. People often miss it — and it is exactly the one to blame when goto() fails on a slow staging environment.
• Global timeout — ліміт на весь прогін цілком, а не на один тест: globalTimeout: 3_600_000 в конфізі. Захищає CI від зависання на години якщо щось пішло зовсім не так.
• Global timeout — a limit on the entire run, not on one test: globalTimeout: 3_600_000 in the config. It protects CI from hanging for hours when something has gone badly wrong.

Ієрархія перевизначення — від загального до конкретного:The override hierarchy — from the general to the specific:

globalTimeout (весь прогін)
    ↓
Конфіг: timeout / expect.timeout / use.actionTimeout / use.navigationTimeout
    ↓ перевизначається
test.describe.configure({ timeout: 60_000 })     ← рівень describe
    ↓ перевизначається
test('...', { timeout: 60_000 }, async () => {}) ← рівень тесту
test.setTimeout(60_000)                          ← всередині тесту
    ↓ перевизначається
await locator.click({ timeout: 10_000 })         ← рівень окремої дії
await expect(locator).toBeVisible({ timeout: 10_000 })  ← рівень assertion

// Чим конкретніше — тим вищий пріоритет. Найточніший виграє.

globalTimeout (entire run)
    ↓
Config: timeout / expect.timeout / use.actionTimeout / use.navigationTimeout
    ↓ overridden by
test.describe.configure({ timeout: 60_000 })     ← describe level
    ↓ overridden by
test('...', { timeout: 60_000 }, async () => {}) ← test level
test.setTimeout(60_000)                          ← inside the test
    ↓ overridden by
await locator.click({ timeout: 10_000 })         ← single action level
await expect(locator).toBeVisible({ timeout: 10_000 })  ← assertion level

// The more specific, the higher the priority. The most specific wins.

⚠️ Чому важливо розрізняти: якщо тест падає з TimeoutError — перше питання "який саме таймаут спрацював?" Класична пастка: збільшила timeout: 60000 в конфізі, а падає все одно через 5 секунд — бо це був expect timeout, він живе окремо в expect: { timeout }. Різний діагноз → різне рішення.

⚠️ Why telling them apart matters: when a test fails with a TimeoutError, the first question is "which timeout fired?" The classic trap: you raised timeout: 60000 in the config and it still fails after 5 seconds — because that was the expect timeout, which lives separately in expect: { timeout }. A different diagnosis means a different fix.

Звичайна перевірка в JavaScript виконується один раз і одразу: отримала значення — порівняла — результат. Але в браузерних тестах UI змінюється асинхронно: кнопка може ще не з'явитись, текст ще не оновитись. Перевірка "зараз" дасть хибний результат.

An ordinary check in JavaScript runs once, immediately: take the value, compare it, done. But in browser tests the UI changes asynchronously: the button may not be there yet, the text may not have refreshed yet. A check for "right now" gives you the wrong answer.

Web-first assertions — це expect(locator).toBeVisible() і подібні. Вони не перевіряють одразу — вони ретраяться з невеликим інтервалом поки умова не стане true або не вийде таймаут. Тобто вони самі чекають потрібного стану.

Web-first assertions are expect(locator).toBeVisible() and friends. They do not check once — they retry at a short interval until the condition is true or the timeout runs out. In other words, they do the waiting for you.

Web-first assertions типу expect(locator).toBeVisible() самі ретраяться — але тільки для DOM-елементів. Що якщо умова яку треба перевірити — не про елемент на сторінці?

Web-first assertions like expect(locator).toBeVisible() retry by themselves — but only for DOM elements. What if the condition you need to check is not about an element on the page at all?

• Чекаємо поки window.analyticsReady === true — глобальна змінна яку встановлює скрипт після ініціалізації
• Waiting until window.analyticsReady === true — a global variable a script sets once it has initialised
• Чекаємо поки в window.dataLayer з'явиться конкретна подія
• Waiting until a specific event shows up in window.dataLayer
• Чекаємо поки кількість елементів у React state досягне певного числа
• Waiting until the number of items in React state reaches some value
• Чекаємо поки анімація завершиться по конкретному CSS property, а не по видимості
• Waiting until an animation finishes, judged by a specific CSS property rather than by visibility

Для всього цього немає локатора. page.waitForFunction() передає довільну JS-функцію яка виконується в браузері і повторюється поки не поверне truthy значення або не вийде таймаут.

None of these has a locator. page.waitForFunction() takes an arbitrary JS function, runs it in the browser and repeats it until it returns a truthy value or the timeout runs out.

Різниця від page.evaluate(): evaluate() виконується один раз і повертає результат. waitForFunction() виконується повторно з інтервалом поки умова не стане true — це evaluate з вбудованим polling.

How it differs from page.evaluate(): evaluate() runs once and returns the result. waitForFunction() runs again and again at an interval until the condition is true — it is evaluate with polling built in.

Як читати код з waitForFunction — по кроках:How to read waitForFunction code, step by step:

await page.waitForFunction(() => {
  return Array.isArray((window as any).dataLayer)
    && (window as any).dataLayer.length > 0;
});

• await — чекаємо поки waitForFunction завершиться. Без нього тест піде далі не чекаючи.
• await — wait for waitForFunction to finish. Without it the test carries on without waiting.
• () => { ... } — стрілочна функція без аргументів. Думай про неї як про "посилку коду яку ми відправляємо в браузер". Вона виконується не в Node.js, а всередині браузера.
• () => { ... } — an arrow function with no arguments. Think of it as "a parcel of code we ship into the browser". It runs inside the browser, not in Node.js.
• window — глобальний об'єкт браузера. Доступний тому що код виконується в браузері.
• window — the browser's global object. Available because this code runs in the browser.
• (window as any) — TypeScript cast щоб компілятор не скаржився що dataLayer не задекларований на типі Window.
• (window as any) — a TypeScript cast so the compiler stops complaining that dataLayer is not declared on the Window type.
• return true/false — якщо повернула truthy → Playwright зупиняється. Якщо falsy → чекає ~100мс і повторює. Якщо за таймаут не стало true → кидає TimeoutError.
• return true/false — a truthy return stops Playwright. A falsy one waits ~100ms and repeats. If it never became true before the timeout, it throws a TimeoutError.

Чому closure не працює і навіщо другий аргумент:Why a closure does not work, and what the second argument is for:

const expected = 48; // змінна в Node.js

// ❌ НЕ ПРАЦЮЄ — браузер не бачить Node.js змінні через closure
await page.waitForFunction(() => {
  return document.querySelectorAll('.product-card').length >= expected; // expected → undefined!
});

// ✅ ПРАВИЛЬНО — передаємо як другий аргумент
// Playwright серіалізує 48 в JSON і передає в браузер як параметр функції
await page.waitForFunction(
  (expectedCount) => {                  // параметр функції
    return document.querySelectorAll('.product-card').length >= expectedCount;
  },
  48                                    // ← стане значенням expectedCount
);

const expected = 48; // a Node.js variable

// ❌ DOES NOT WORK — the browser can't see Node.js variables via closure
await page.waitForFunction(() => {
  return document.querySelectorAll('.product-card').length >= expected; // expected → undefined!
});

// ✅ CORRECT — pass it as the second argument
// Playwright serializes 48 to JSON and passes it to the browser as a function parameter
await page.waitForFunction(
  (expectedCount) => {                  // function parameter
    return document.querySelectorAll('.product-card').length >= expectedCount;
  },
  48                                    // ← becomes the value of expectedCount
);

Коли потрібен async всередині:When you need async inside:

// async потрібен якщо всередині браузера треба зробити fetch
await page.waitForFunction(async () => {
  const response = await fetch('/api/status'); // fetch — браузерний API
  const data = await response.json();
  return data.status === 'ready';
});
// В більшості випадків async не потрібен — window/document/CSS синхронні

// async is needed if you have to fetch inside the browser
await page.waitForFunction(async () => {
  const response = await fetch('/api/status'); // fetch is a browser API
  const data = await response.json();
  return data.status === 'ready';
});
// Most of the time async isn't needed — window/document/CSS are synchronous

expect.poll() — асинхронний polling: ретраїть довільну async функцію в Node.js кожні N мс до таймауту. Ідеально для зовнішніх станів (БД, email, API) де немає DOM-елемента для перевірки.

expect.poll() is asynchronous polling: it retries an arbitrary async function in Node.js every N ms until the timeout. Ideal for external state (a database, email, an API) where there is no DOM element to check.

Це не окремий механізм. expect.poll() використовує той самий retry-loop що й звичайні web-first assertions — просто замість того щоб повторно резолвити Locator, він повторно викликає твою функцію і передає результат у матчер. Тому і таймаути, і поведінка ретраїв тут ідентичні expect(locator).toBeVisible().

It is not a separate mechanism. expect.poll() uses the same retry loop as ordinary web-first assertions — instead of resolving a Locator again, it calls your function again and hands the result to the matcher. Which is why the timeouts and the retry behaviour here are identical to expect(locator).toBeVisible().

Три схожі механізми які часто плутають:Three similar mechanisms people often mix up:

• expect.poll(async () => value).toBe(x) — ретраїть функцію в Node.js, передає її результат у матчер. Для перевірки значення що змінюється з часом: статус в API, кількість листів, запис у БД.
• expect.poll(async () => value).toBe(x) — retries a function in Node.js and passes its result to the matcher. For checking a value that changes over time: a status in an API, a number of emails, a row in a database.
• await expect(async () => {...}).toPass() — ретраїть функцію яка сама містить assertions. Не повертає значення — просто повторює блок поки всі assertions всередині не пройдуть. Для ретраю групи перевірок разом.
• await expect(async () => {...}).toPass() — retries a function that contains assertions itself. It returns nothing — it just repeats the block until every assertion inside passes. For retrying a group of checks together.
• page.waitForFunction(() => ...) — це інша категорія: виконує код всередині браузера, а не в Node.js. Має доступ до window, document. Не є заміною expect.poll() — вони працюють у різних середовищах.
• page.waitForFunction(() => ...) — this is a different category: it runs code inside the browser, not in Node.js. It has access to window and document. It is not a replacement for expect.poll() — they work in different environments.

Просте правило: перевіряєш значення з Node.js (API, БД) → expect.poll(). Ретраїш блок assertions → toPass(). Потрібен доступ до window/document → waitForFunction(). Перевіряєш DOM-елемент → звичайний web-first assertion, нічого з цього не треба.

A simple rule: checking a value from Node.js (an API, a database) → expect.poll(). Retrying a block of assertions → toPass(). Need access to window/document → waitForFunction(). Checking a DOM element → a plain web-first assertion, none of this is needed.

Вбудовані matchers Playwright — toBeVisible(), toHaveText() — покривають загальні випадки. Custom matchers потрібні коли одна і та сама складна перевірка повторюється в багатьох тестах — але навіть тоді спочатку варто розглянути простішу альтернативу.

Playwright's built-in matchers — toBeVisible(), toHaveText() — cover the common cases. You need a custom matcher when the same complicated check repeats across many tests — and even then it is worth looking at the simpler alternative first.

Простіша альтернатива — helper функція:The simpler alternative — a helper function:

// helpers/assertions.ts — просто функція
function expectValidPrice(price: string) {
  expect(price).toMatch(/^\£\d+\.\d{2}$/);
  expect(price).not.toBe('');
  expect(parseFloat(price.replace('£', ''))).toBeGreaterThan(0);
}

// В тесті — те саме що custom matcher, але простіше:
expectValidPrice(price);

// helpers/assertions.ts — just a function
function expectValidPrice(price: string) {
  expect(price).toMatch(/^\£\d+\.\d{2}$/);
  expect(price).not.toBe('');
  expect(parseFloat(price.replace('£', ''))).toBeGreaterThan(0);
}

// In the test — same as a custom matcher, but simpler:
expectValidPrice(price);

Єдина реальна перевага custom matcher над helper — повідомлення при падінні:The one real advantage a custom matcher has over a helper is the failure message:

// Helper падає так:
// Expected: match /^\£\d+\.\d{2}$/
// Received: "abc"

// Custom matcher падає так:
// Expected price to be valid product price format
// Received: "abc"

// A helper fails like this:
// Expected: match /^\£\d+\.\d{2}$/
// Received: "abc"

// A custom matcher fails like this:
// Expected price to be valid product price format
// Received: "abc"

Просте правило: helper функція — простіше, зрозуміліше, достатньо для 99% випадків. Custom matcher — тільки якщо важливо мати читабельне повідомлення при падінні яке точно описує що саме перевіряється. Якщо перевірка зустрічається 1-2 рази — просто напиши inline.

A simple rule: a helper function is simpler, clearer, and enough for 99% of cases. A custom matcher is worth it only when it matters to have a readable failure message that says exactly what is being checked. If the check appears once or twice, just write it inline.

Shadow DOM — механізм браузера для інкапсуляції компонентів. Елементи всередині shadow root ізольовані від основного документу. Використовується в Web Components і деяких UI бібліотеках.

The Shadow DOM is a browser mechanism for encapsulating components. Elements inside a shadow root are isolated from the main document. It is used by Web Components and by some UI libraries.

Добра новина: Playwright автоматично "пронизує" open shadow root при пошуку локаторами. В більшості випадків нічого особливого робити не треба.

The good news: Playwright pierces an open shadow root automatically when locators look things up. Most of the time there is nothing special to do.

Ми вже розібрали що таке fixtures концептуально і чому page/context/browser так називаються. Тепер подивимось на всі вбудовані fixtures разом — і коли який використовувати.

We have already covered what fixtures are conceptually and why page/context/browser are named the way they are. Now let's look at all the built-in ones together — and when to reach for which.

Fixtures — це механізм dependency injection. Вбудовані: page, browser, context, request.

Fixtures are a dependency injection mechanism. The built-in ones: page, browser, context, request.

Scope вбудованих fixtures: page, context, request — test-scoped (створюються заново для кожного тесту). browser — worker-scoped (один на весь worker-процес, не на весь прогін). При паралельному запуску з 4 workers — буде 4 окремих браузерних процеси.

Scope of the built-in fixtures: page, context, request are test-scoped (recreated from scratch for every test). browser is worker-scoped (one per worker process, not one per run). Run in parallel with 4 workers and you get 4 separate browser processes.

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

The problem: when every test has to do the same thing — open a page and log in, say — those lines get duplicated everywhere. A custom fixture removes the duplication: you describe the preparation once and just ask for it by name in the test.

Fixture — три частини:

A fixture has three parts:

myFixture: async ({ page }, use) => {
  // 1. SETUP — виконується ДО тесту
  await page.goto('/cart');

  await use(page); // 2. use() — Playwright зупиняється тут і запускає тест
                   //    коли тест завершився — Playwright повертається сюди

  // 3. TEARDOWN — виконується ПІСЛЯ тесту (навіть якщо тест впав)
  await page.goto('/');
}

myFixture: async ({ page }, use) => {
  // 1. SETUP — runs BEFORE the test
  await page.goto('/cart');

  await use(page); // 2. use() — Playwright pauses here and runs the test
                   //    when the test finishes, Playwright comes back here

  // 3. TEARDOWN — runs AFTER the test (even if the test failed)
  await page.goto('/');
}

use() — розділювач між setup і teardown. Без нього Playwright не знав би коли запускати тест. В use() передаємо будь-що що підготували — page, об'єкт, рядок або undefined. В тесті пишемо ім'я fixture в деструктуризації — воно має збігатись з назвою в extend().

use() is the divider between setup and teardown. Without it Playwright would have no idea when to run the test. Into use() you pass whatever you prepared — a page, an object, a string or undefined. In the test you write the fixture name in the destructuring, and it has to match the name in extend().

Fixture vs beforeEach:

Fixture vs beforeEach:

• beforeEach достатньо — коли треба просто відкрити сторінку і нічого більше
• Fixture краща — коли є teardown (в одному місці), коли треба передати значення в тест (beforeEach не може), або коли той самий setup потрібен у кількох файлах

• beforeEach is enough — when you just need to open a page and nothing else
• A fixture is better — when there is teardown (kept in one place), when you need to hand a value to the test (beforeEach can't), or when the same setup is needed in several files

Fixture vs глобальна змінна (let db: any):

Fixture vs a global variable (let db: any):

Глобальна змінна ламається при паралельному виконанні — кілька тестів одночасно пишуть в одну змінну. Fixture дає кожному тесту свій власний екземпляр ресурсу. Плюс якщо setup впав — fixture кидає зрозумілу помилку, а глобальна змінна лишається undefined.

A global variable falls apart under parallel execution — several tests write to the same variable at once. A fixture gives every test its own instance of the resource. And if the setup fails, the fixture throws an error you can read, whereas the global variable just quietly stays undefined.

Кастомні fixtures розширюють вбудовані — додають авторизацію, page objects або тестові дані.

Custom fixtures extend the built-in ones — they add authentication, page objects or test data.

Навіщо {} першим аргументом: перший параметр fixture — це об'єкт де ти запитуєш інші fixtures. Якщо потрібен page — пишеш { page }. Якщо нічого не потрібно — все одно треба поставити щось на місці першого параметра бо функція приймає два аргументи: (fixtures, use). Тому пишемо {} — порожня деструктуризація, означає "перший аргумент є але мені нічого з нього не треба".

Why {} as the first argument: the first parameter of a fixture is the object where you ask for other fixtures. Need page? You write { page }. Need nothing at all? You still have to put something in that first slot, because the function takes two arguments: (fixtures, use). So you write {} — an empty destructuring, meaning "there is a first argument but I want nothing out of it".

Ключовий момент: Playwright не запускає всі fixtures проєкту перед кожним тестом. Він дивиться лише на те, що тест реально попросив у своїй сигнатурі — async ({ page }) проти async ({ authenticatedPage }) — і будує тільки той підграф залежностей, який потрібен саме для цього набору. Якщо authenticatedPage внутрішньо запитує { page }, Playwright спочатку створить page, а решту fixtures проєкту навіть не торкне. Fixture по суті не каже "виконай це" — вона каже "ось що мені потрібно, щоб працювати", а Playwright сам вирішує що і в якому порядку створити виходячи з цих запитів.

The key point: Playwright does not run every fixture in the project before each test. It looks only at what the test actually asked for in its signature — async ({ page }) versus async ({ authenticatedPage }) — and builds just the dependency subgraph that this particular set needs. If authenticatedPage internally asks for { page }, Playwright creates page first and never touches the rest of the project's fixtures at all. A fixture doesn't really say "run this" — it says "here is what I need in order to work", and Playwright works out what to create, and in what order, from those requests.

// Потрібен page — беремо його
loginPage: async ({ page }, use) => { await use(new LoginPage(page)); }

// Нічого не потрібно — порожня деструктуризація
dbConnection: async ({}, use) => { const db = await connectDB(); await use(db); }

// Need page — take it
loginPage: async ({ page }, use) => { await use(new LoginPage(page)); }

// Need nothing — empty destructuring
dbConnection: async ({}, use) => { const db = await connectDB(); await use(db); }

У @playwright/test fixture — це функція async ({ …deps }, use) => { … }. Код до await use(value) — setup, сам виклик use() — це час, коли виконується тест, код після нього — teardown. Інших форм немає: fixture завжди отримує use другим аргументом.

In @playwright/test a fixture is an async ({ …deps }, use) => { … } function. The code before await use(value) is setup, the use() call itself is when the test runs, and the code after it is teardown. There is no other form: a fixture always receives use as its second argument.

Коли тест падає, await use() все одно повертається, і Playwright виконує код після нього. Тож звичайний teardown після use() вже спрацює при впалому тесті. try/finally потрібен в іншому випадку: коли падає сам setup на півдорозі, або коли ресурсів кілька і кожен треба прибрати, навіть якщо прибирання попереднього кинуло помилку.

When the test fails, await use() still returns and Playwright runs the code after it. So a plain teardown after use() already runs for a failed test. You need try/finally for a different case: when the setup itself fails halfway, or when there are several resources and each must be released even if releasing the previous one threw.

Пастка на співбесіді: «yield-фікстури» — це pytest (Python): yield driver у функції з @pytest.fixture. У Playwright для TypeScript/JavaScript генераторних фікстур немає; async function* у test.extend() просто не спрацює.

Interview trap: "yield fixtures" are pytest (Python): yield driver inside an @pytest.fixture function. Playwright for TypeScript/JavaScript has no generator fixtures; an async function* inside test.extend() simply won't work.

Worker — це окремий Node.js процес який Playwright запускає для виконання тестів. Якщо у тебе workers: 4 в конфізі — Playwright запускає 4 окремих процеси, і кожен виконує свою частину тестів.

A worker is a separate Node.js process that Playwright starts to run tests in. If your config says workers: 4, Playwright starts 4 separate processes, and each one runs its share of the tests.

Test-scoped (за замовчуванням) — fixture створюється заново для кожного тесту і знищується після нього. Кожен тест отримує чисту ізольовану копію:

Test-scoped (the default) — the fixture is created from scratch for every test and destroyed after it. Every test gets a clean, isolated copy:

Worker 1:
  Тест 1 → створити fixture → тест → знищити fixture
  Тест 2 → створити fixture → тест → знищити fixture
  Тест 3 → створити fixture → тест → знищити fixture

Worker 1:
  Test 1 → create fixture → test → destroy fixture
  Test 2 → create fixture → test → destroy fixture
  Test 3 → create fixture → test → destroy fixture

Worker-scoped — fixture створюється один раз коли worker стартує і знищується коли worker завершує роботу. Всі тести в цьому worker використовують одну і ту саму копію:

Worker-scoped — the fixture is created once when the worker starts and destroyed when the worker finishes. Every test in that worker uses the same copy:

Worker 1:
  → створити fixture (один раз)
  Тест 1 → використовує fixture
  Тест 2 → використовує ту саму fixture
  Тест 3 → використовує ту саму fixture
  → знищити fixture (один раз)

Worker 1:
  → create fixture (once)
  Test 1 → uses the fixture
  Test 2 → uses the same fixture
  Test 3 → uses the same fixture
  → destroy fixture (once)

Навіщо worker-scoped? Коли fixture дорога у створенні — наприклад підключення до бази даних займає 2 секунди. Якщо test-scoped — підключення відбувається для кожного тесту. Якщо worker-scoped — підключення один раз і всі тести в цьому worker використовують його.

Why worker-scoped? When the fixture is expensive to create — a database connection that takes 2 seconds, say. Test-scoped means connecting once per test. Worker-scoped means connecting once, and every test in that worker reuses it.

Важливо: worker-scoped fixtures не шаряться між різними workers. Worker 1 і Worker 2 мають свої окремі екземпляри — ізоляція між workers зберігається.

Important: worker-scoped fixtures are not shared between workers. Worker 1 and Worker 2 have their own separate instances — the isolation between workers stays intact.

Звичайна фікстура виконується тільки якщо ти явно вказала її в параметрах тесту:

An ordinary fixture only runs if you explicitly name it in the test's parameters:

test('мій тест', async ({ page, myFixture }) => { ... })
//                                  ↑ треба явно попросити

test('my test', async ({ page, myFixture }) => { ... })
//                                 ↑ must be requested explicitly

auto: true змінює це — фікстура виконується для кожного тесту автоматично, навіть якщо тест про неї нічого не знає і не вказував її в параметрах.

auto: true changes that — the fixture runs for every test automatically, even if the test knows nothing about it and never listed it in its parameters.

Навіщо це потрібно? Є речі які треба робити перед або після кожного тесту, але не хочеться засмічувати параметри кожного тесту:

Why would you want that? There are things you have to do before or after every test, and you would rather not clutter every test's parameter list with them:

• Логувати початок і кінець кожного тесту в зовнішню систему
• Перевіряти що немає JS-помилок на сторінці після кожного тесту
• Встановлювати глобальний мок для аналітики щоб вона не заважала тестам
• Робити скріншот після кожного тесту незалежно від результату

• Log the start and the end of every test to an external system
• Check there were no JS errors on the page after every test
• Install a global mock for analytics so it stops interfering with the tests
• Take a screenshot after every test, whatever the outcome

Різниця від beforeEach: auto: true fixture визначається один раз у спільному файлі і автоматично застосовується до всіх тестів які використовують цей test.extend(). beforeEach можна винести в базовий test або shared helper, але auto fixtures масштабуються значно краще — setup і teardown в одному місці, не потрібен окремий afterEach, і типізація через TypeScript працює автоматично.

How it differs from beforeEach: an auto: true fixture is defined once in a shared file and applies automatically to every test that uses that test.extend(). beforeEach can be lifted into a base test or a shared helper, but auto fixtures scale noticeably better — setup and teardown live in one place, you need no separate afterEach, and the TypeScript typing comes along for free.

Ми вже знаємо як виконати одну дію в тесті. Але коли тестів багато — кожен з них потребує схожого підготовчого кроку: відкрити певну сторінку, залогінитись, підготувати тестові дані. Писати це в кожному тесті окремо — дублювання. Саме для цього існують хуки.

We already know how to do one thing inside a test. But once there are a lot of tests, each of them needs a similar preparation step: open a particular page, log in, seed some test data. Writing that out in every test is duplication. Hooks exist for exactly that.

Хуки — це функції що Playwright викликає автоматично у визначений момент: до тесту, після тесту, до всіх тестів в блоці, після всіх. Вони живуть всередині test.describe() і діють тільки на тести цього блоку.

Hooks are functions Playwright calls automatically at a defined moment: before a test, after a test, before all the tests in a block, after all of them. They live inside test.describe() and only affect the tests of that block.

Важливо про scope: beforeAll/afterAll виконуються один раз на worker, а не на весь прогін. При паралельному запуску з кількома workers — beforeAll виконається в кожному worker окремо. Якщо потрібно щоб код виконався рівно один раз для всього прогону — використовуй globalSetup або project dependencies.

Important about scope: beforeAll/afterAll run once per worker, not once per run. Run in parallel with several workers and beforeAll runs in each worker separately. If you need code to run exactly once for the whole run, use globalSetup or project dependencies.

Коли є один describe — все очевидно: beforeAll → beforeEach → тест → afterEach → afterAll. Але коли describe вкладені — порядок стає менш очевидним і це часто плутають.

With a single describe it's obvious: beforeAll → beforeEach → test → afterEach → afterAll. But once describes are nested the order gets less obvious, and this is a common one to get wrong.

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

The base rule: hooks run outside-in on the way in and inside-out on the way out. Picture the layers of an onion — you take the outer layer off first, then the inner one. On the way back out it's the other way round.

зовнішній beforeAll        ← виконується ОДИН РАЗ перед усіма тестами
  внутрішній beforeAll     ← виконується ОДИН РАЗ перед тестами вкладеного describe
    зовнішній beforeEach   ← для КОЖНОГО тесту
      внутрішній beforeEach ← для КОЖНОГО тесту у вкладеному describe
        → ТЕСТ
      внутрішній afterEach  ← для КОЖНОГО тесту
    зовнішній afterEach    ← для КОЖНОГО тесту
  внутрішній afterAll      ← ОДИН РАЗ після всіх тестів вкладеного describe
зовнішній afterAll         ← ОДИН РАЗ після ВСІХ тестів включно з вкладеними

outer beforeAll        ← runs ONCE before all tests
  inner beforeAll      ← runs ONCE before the nested describe's tests
    outer beforeEach   ← for EVERY test
      inner beforeEach ← for EVERY test in the nested describe
        → TEST
      inner afterEach  ← for EVERY test
    outer afterEach    ← for EVERY test
  inner afterAll       ← ONCE after all tests of the nested describe
outer afterAll         ← ONCE after ALL tests, including nested ones

• Проблема 1: beforeAll зовнішнього describe виконується для всіх тестів включно з вкладеними — навіть якщо setup потрібен тільки для зовнішніх тестів
• Проблема 2: якщо зовнішній beforeEach встановлює стан, а внутрішній перевизначає — зовнішній все одно виконається першим
• Проблема 3: afterAll зовнішнього describe чекає поки завершаться ВСІ вкладені describe включно з їх afterAll

• Problem 1: the outer describe's beforeAll runs for every test, nested ones included — even when the setup is only needed by the outer tests
• Problem 2: if the outer beforeEach sets some state and the inner one overrides it, the outer one still runs first
• Problem 3: the outer describe's afterAll waits for EVERY nested describe to finish, their own afterAll included

Природний рефлекс: зберегти спільне значення в глобальну змінну. В Playwright це працює по-різному залежно від налаштувань — і розуміння цього допомагає уникнути неочевидних багів.

The natural reflex is to stash the shared value in a global variable. In Playwright that behaves differently depending on your settings — and understanding why saves you from some non-obvious bugs.

При fullyParallel: false (за замовчуванням) — весь файл виконується в одному worker. Тести в одному файлі йдуть послідовно, тому глобальна змінна на рівні файлу працює для тестів цього файлу:

With fullyParallel: false (the default) — the whole file runs in one worker. Tests in the same file go one after another, so a file-level global variable does work for the tests of that file:

// product.spec.ts — всі тести в одному worker
let sharedData: string;

test.beforeAll(async () => { sharedData = 'готово'; });
test('тест 1', async () => { console.log(sharedData); }); // ✅ бачить
test('тест 2', async () => { console.log(sharedData); }); // ✅ бачить