Асинхронність у Cypress та Playwright реалізована абсолютно по-різному, і це одна з головних концептуальних відмінностей між цими фреймворками. 1. Cypress: Ланцюжки команд та власна черга (Cypress Queue) Код у Cypress виглядає синхронним, але насправді він використовує ланцюжки команд (Command Chaining) та внутрішню чергу виконання. JavaScript 2. Playwright: Нативний асинхронний JavaScript (async/await) Playwright повністю побудований на […]
Ми вже знаємо що таке Node.js, WebSocket, ієрархія браузера і fixtures. Час написати перший реальний тест — і ти побачиш як всі ці концепти з’єднуються разом. Базовий тест складається з трьох частин: імпорт test і expect з Playwright, оголошення тесту через функцію test() з назвою і async функцією, і деструктуризація fixtures { page } — […]
“Fixture” — це офіційний термін у Playwright, не метафора. Слово прийшло з будівництва і спорту — це щось “зафіксоване”, підготовлене заздалегідь і готове до використання. У тестуванні fixture — це будь-який ресурс, який фреймворк готує для тебе до запуску тесту і прибирає після. Саме тому page, browser, context — це фікстури: ти їх не створюєш […]
В Cypress та Playwright термін «фікстура» (fixture) використовується в різному контексті та вирішує різні завдання, хоча обидва інструменти призначені для автоматизації тестування. 1. Фікстури в Cypress У Cypress під fixture розуміють статичні тестові дані (зазвичай у форматі JSON, TXT або зображень), які зберігаються в папці cypress/fixtures. 2. Фікстури в Playwright У Playwright під fixture розуміють […]
Фікстура — це готовий ресурс який Playwright сам підготував і передав у тест. Ти просто називаєш що тобі потрібно — і отримуєш це готовим. Після тесту Playwright сам прибирає. Аналогія з рестораном: ти не ходиш на кухню щоб взяти тарілку — офіціант приносить її сам. Ти просто замовляєш “мені потрібна тарілка” і отримуєш готову. Fixture […]
Ми щойно розібрались як Playwright спілкується з браузером через WebSocket і CDP. Тепер подивимось на структуру самого браузера — три рівні ієрархії які пояснюють чому тести ізольовані один від одного навіть при паралельному запуску. Browser — це сам процес браузера (Chromium, Firefox або WebKit). Дорогий у запуску, тому Playwright тримає один на кожен worker (процес виконання). При паралельному […]
Щоб зрозуміти CDP — спочатку треба розділити два рівні які не мають між собою нічого спільного. Рівень 1 — код аплікейшину (твій React/JS сайт) Звичайний JavaScript який виконується всередині браузера. Взаємодіє з браузером через вбудовані браузерні API — document, window, fetch. Ніякого CDP тут немає. Рівень 2 — CDP (Chrome DevTools Protocol) Канал для зовнішніх програм які хочуть керувати браузером […]
Щоб зрозуміти WebSocket — спочатку треба зрозуміти як працює звичайний HTTP. HTTP запит — як SMS: Ти відправляєш повідомлення → сервер відповідає → з’єднання закривається. Щоразу коли треба щось отримати — треба відправити новий запит. Кожен запит це окреме з’єднання яке відкривається і закривається. Ефективно для сайтів де дані рідко змінюються — завантажив сторінку, все, […]
Node.js — це середовище де може виконуватись JavaScript поза браузером. Спочатку JavaScript існував тільки в браузері — міг маніпулювати DOM, реагувати на кліки, відправляти запити. Але не міг читати файли з диску, запускати сервер, чи взаємодіяти з операційною системою. Node.js змінив це у 2009 — взяв JavaScript рушій з Chrome (V8) і запустив його окремо як […]
Уяви, що Playwright Test ще не існує — є тільки сама бібліотека playwright: Це не тест — це просто Node.js-програма що відкриває браузер. На цьому рівні Playwright — бібліотека автоматизації браузера, як Express для HTTP чи React для UI. Вона нічого не знає про test(), expect(), beforeEach, retries чи паралельний запуск. Це і є причина плутанини: у npm справді існують […]
© <it/>Praktik 2026. Powered by WordPress