Ландшафт інструментів: Selenium, Playwright, Cypress, CodeceptJS

Зміст

У вакансії написано «Selenium або Playwright», у статті — «Cypress швидший», у чужому репозиторії лежить CodeceptJS. Виглядає так, ніби це чотири синтаксиси для однієї дії «клікни по кнопці», і вибір між ними — питання смаку. Насправді ці інструменти різняться не набором команд, а тим, як тестовий код дістається до браузера. Саме ця відповідь визначає, якою мовою ви пишете тести, чи можете завести двох користувачів в одному сценарії, чи побачите справжній Safari й чи поїде той самий тест на віддалену машину без жодної правки.

Тому питання «що обереш і чому» — про архітектуру, а не про фічі. «Playwright, бо він швидший і має trace viewer» — це перелік ярликів. «Залежить від того, чи потрібна мовна незалежність і чи є в сценаріях два браузери одночасно» — це вже (browser control model), і саме вона визначає, що інструмент дозволить, а що ні. Ця глава — про три такі моделі та їхню ціну.

Три моделі керування браузером

Чотири назви з заголовка розкладаються на три моделі, і кожна дає власні межі.

Модель 1 — wire-протокол поза процесом браузера. Її нормативний опис живе у специфікації W3C: WebDriver — це інтерфейс дистанційного керування з платформо- і мовно-нейтральним wire-протоколом для програм, що працюють поза процесом браузера. Призначення названо прямо: дати авторам писати тести, які автоматизують браузер з окремого керувального процесу. Ланцюг вузлів у специфікації теж названий поіменно — local end (мовна бібліотека поверх протоколу), intermediary node (, що реалізує обидва боки) і endpoint node, реалізований самим браузером. Найважливіша вимога: будь-який віддалений вузол мусить бути невідрізнимим як чорна скринька з погляду клієнта. Разом ці дві речі — нейтральний протокол і невідрізнимість вузлів — дають головні властивості моделі: будь-яку мову клієнта й той самий тест на локальному драйвері та на віддаленій машині.

Модель 2 — власний протокол інструмента. Тут інструмент розділений надвоє: бібліотека дає єдину API для запуску браузерів і взаємодії з ними, а (test runner) додає до неї повністю керований наскрізний прогін. Окремих драйверів під кожен браузер немає взагалі: браузери й системні залежності ставить власна CLI-команда інструмента. Ціна цієї зручності — браузери свої: за замовчуванням це відкрита збірка Chromium, а не Google Chrome, і вона на версію попереду брендового браузера.

Модель 3 — виконання всередині браузера. Команди виконуються в браузері, і сам інструмент називає це постійним компромісом (permanent trade-off), а не тимчасовим обмеженням. Наслідок: немає серіалізації обʼєктів і wire-протоколів, є прямий доступ до всього в застосунку. Зворотний бік того самого — тестовий код теж виконується в браузері, а не в Node, і мовою назавжди лишається JavaScript.

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

Що модель означає на практиці

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

Ось	`wire`-протокол	Власний протокол	Виконання в браузері
Мова тесту	будь-яка: протокол мовно-нейтральний	мови, під які є офіційна бібліотека (TypeScript, Python, .NET, Java)	лише JavaScript (і те, що в нього компілюється)
Де живе тестовий код	у власному процесі поза браузером	у власному процесі (Node)	всередині браузера
Хто постачає браузер	окремий драйвер до вже наявного браузера	сам інструмент, власними збірками	той браузер, у якому все й виконується
Доступ до серверного коду з тесту	напряму зі свого процесу	напряму зі свого процесу	лише через команди-містки

Головне, що варто винести з таблиці: мовна незалежність і віддалене виконання ростуть із wire-протоколу, і «той самий тест поїхав у ферму» — не фіча конкретного інструмента, а вимога специфікації. Проміжний вузол-проксі там оголошений законною частиною моделі й зобовʼязаний бути невідрізнимим від звичайного віддаленого кінця, тож тест про підключення до (browser farm) не знає нічого — деталі виносить глава «Паралельний запуск: workers, шардінг, браузерні ферми».

Дзеркально працює й третя модель. «Двома браузерами водночас не керуємо» — не недоробка: інструмент сам перелічує це серед постійних компромісів разом із «тест привʼязаний до одного супердомену» (перехід на інше вмикається окремою командою cy.origin). І окремо, свідомо, дока веде другий список — тимчасових обмежень, куди йдуть нативні події й неповна робота з iframe. Перший список читається як опис архітектури, другий — як .

Із тієї самої моделі випливає й прикладна незручність: серверні бібліотеки в браузер не імпортуються, тож підготовка даних іде через окремі команди-містки (cy.exec, cy.task, cy.request), а бази доводиться спеціально виставляти назовні. У першій і другій моделях тест живе у власному процесі й відкриває зʼєднання до бази прямо з коду. Це не «краще-гірше» — це різні ціни за різні вигоди.

Selenium: парасольковий проєкт, а не бібліотека

Питання «що таке Selenium» має точну відповідь у самій документації проєкту, і вона не збігається з розхожим переказом. Selenium — це (umbrella project) із набору інструментів і бібліотек, а не один інструмент. Дає він три речі: розширення для емуляції взаємодії користувача, сервер розподілу для масштабування виділення браузерів і інфраструктуру реалізацій специфікації W3C WebDriver, завдяки якій код лишається взаємозамінним між усіма основними браузерами. У ядрі — WebDriver, і дока називає його саме interface для написання наборів інструкцій, а не «драйвером» і не «бібліотекою».

Звідси головний висновок, який і варто називати першим: кросбраузерність Selenium тримається на стандарті W3C, а не на власному протоколі проєкту. Продовження того самого — природа проєкту: він тримається на волонтерах, код вільно доступний. Тобто за сумісність відповідає спільнота плюс стандарт, а не вендор.

Екосистема в офіційній доці розділена поіменно: WebDriver, Grid, IDE, Selenium Manager і окремий розділ практик. Наявність Selenium Manager у цьому переліку — та деталь, якої часто бракує: керування драйверами тепер частина самого проєкту. Розділ практик має явний поділ на заохочені (Encouraged) і не заохочені (Discouraged); серед заохочених — models, незалежність тестів і свіжий браузер на тест. Модальність порад варто читати дослівно: fluent API там стоїть як Consider using, тобто рекомендація до розгляду, а не припис.

А чому Selenium досі варто розуміти навіть тим, хто пише на JS? Ринкової статистики ця глава свідомо не наводить: перевірених цифр про вакансії тут немає, а вигадувати їх на співбесіді гірше, ніж чесно сказати «не знаю». Але архітектурна причина цілком джерельна, і для відповіді її досить: протокол мовно нейтральний (тож накопичені на Java, C# і Python ніхто не переписуватиме заради нового інструмента), сумісність описана стандартом, а не вендором, а віддалене виконання вбудоване в саму модель — перенести прогін на іншу машину означає змінити точку підключення, а не тести.

Playwright і Cypress: де саме проходить компроміс

Друга модель платить за зручність тим, що браузери в неї власні — і платить чесно, у документації. Інструмент водить три рушії (Chromium, WebKit, Firefox) плюс брендові канали Chrome і Edge, а емуляція планшетів і мобільних — окремий режим, не окремий рушій. Але Firefox і WebKit тут — патчені збірки: з брендовими Firefox і Safari інструмент не працює, бо покладається на патчі. Тобто «перевіримо в Safari» через цей інструмент означає «перевіримо в найсвіжішій збірці WebKit», і це різні твердження. Мало того, той самий рушій на різних ОС поводиться по-різному — медіакодеки названі поіменно, тож «WebKit у Linux-CI» і «WebKit на mac» не взаємозамінні. Наслідок для матриці браузерів розібраний у главі «Кросбраузерність і адаптивна верстка».

Друга половина компромісу — те, що ранер додає до бібліотеки. У бібліотеці рівні browser → context → page створюються вручну й по черзі, і закривати їх — обовʼязок вашого коду. Ранер віддає тесту вже ізольовані page і context як вбудовані , створює їх ліниво (лише якщо тест назвав їх у своїх аргументах) і закриває сам. Кожен тест дістає свіжий (browser context), еквівалентний новому профілю, — ізоляція майже без накладних витрат. Ранер також приносить web-first assertions, що самі очікують і перезапускають умову, і матрицю конфігурацій в одному місці замість правок скрипта під кожен браузер. Деталі — у главах «Playwright: архітектура, браузери і контексти» і «Playwright: перевірки (assertions) і автоочікування (auto-waiting)».

import { test, expect } from '@playwright/test';

test('гість бачить кнопку входу', async ({ page }) => {
  await page.goto('/');
  // page і context дала фікстура ранера; асерт сам чекає й повторює умову
  await expect(page.getByRole('button', { name: 'Увійти' })).toBeVisible();
});

Окрема пастка тієї самої моделі — безголовий режим. Для нього постачається окремий бінарник chromium headless shell, а не та сама збірка з прапорцем; нове headless-ядро брендових браузерів поводиться інакше, і дока прямо просить очікувати різницю. Практичний наслідок: «локально headed зелене, у CI headless червоне» цілком може бути різницею збірок, а не логіки застосунку.

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

CodeceptJS і надбудови: один сценарій, різні бекенди

Четвертий інструмент із назви глави — не четверта модель, а шар над моделями. Тести тут пишуться як лінійний сценарій дій користувача, а обʼєкт I — це (actor): абстракція користувача-тестувальника й водночас проксі до ввімкнених хелперів (helper). Актор нічого не виконує сам: усі команди делегуються хелперу-бекенду. Бекенди названі поіменно — Playwright (власний протокол), WebDriver (wire-протокол), Puppeteer (протокол DevTools): надбудова накриває перші дві моделі, а виконання всередині браузера серед її бекендів немає.

// той самий сценарій піде на будь-якому з бекендів
Scenario('гість бачить кнопку входу', ({ I }) => {
  I.amOnPage('/');
  I.see('Увійти', 'button');
});

Тест виглядає синхронним, бо всі дії загорнуті в глобальний ланцюг; await потрібен не завжди, а за жорстким правилом — для команд, що починаються з grab, і для викликів імпортованих функцій та методів page object. Очікування вбудоване в дії, а невдалий крок повторюється автоматично — тобто тут живе на рівень нижче за ретрай тесту.

І головний компроміс надбудови стоїть рівно тут. Хелпери мають спільну API, тож перемкнути бекенд легко — але джерело саме ставить межу: через відмінності бекендів сумісність не гарантована, і контрприклад дока наводить власний: заголовки запиту ставляться в Playwright і Puppeteer, а у WebDriver ні. Порада сформульована як вибір: узяти один хелпер, а міграцію робити, якщо зміняться вимоги. Два найважливіші налаштування конфігурації — саме який хелпер (тобто який рушій виконує) і базовий URL застосунку; перемикання між рушіями окремий пакет (@codeceptjs/configure) робить «per-helper translation … automatically». Сценарний стиль і хелпери детально розібрані в главі «CodeceptJS: актор, хелпери і сценарний стиль».

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

Критерії вибору: з чого починати відповідь

Порядок міркування в силабусі ISTQB CTAL-TAE названий прямо: спершу аналіз системи під тестом, потім склад і досвід команди. Це рівно навпаки до того, як вибір нерідко роблять на практиці («візьмемо те, що модне»). Із того самого джерела — ще два аргументи, які добре звучать на інтервʼю: тестувальникам, які програмують, силабус радить брати інструмент, чия мова збігається з мовою системи під тестом, і причина названа — спільний дебаг із розробниками й перехресне навчання; а для команди без досвіду програмування low-code / no-code рішення силабус називає життєздатним вибором, а не поразкою.

Другу половину критеріїв дає не інструмент, а продукт. Покрити геть усі браузери й пристрої практично неможливо, тому діапазон підтримки — домовленість із власником продукту, а матриця будується з даних про аудиторію, а не з уподобань команди. Практичний наслідок: браузери на спільному (Chrome, Edge, Opera) не потребують окремих рядків матриці для більшості перевірок верстки — а от Safari потребує, і саме на ньому друга модель показує свою межу: патчена збірка WebKit брендовим Safari не є. Мінімальний кістяк для проєкту без особливих вимог дає базовий набір Baseline: Chrome (десктоп і Android), Edge, Firefox (десктоп і Android), Safari (macOS та iOS).

І останнє, бо це поширена управлінська помилка: силабус CTFL говорить про категорії інструментів, а не про конкретні бібліотеки, і прямо застерігає — «просте придбання інструмента успіху не гарантує».

Типові помилки

Виглядає як «перевірили в Safari», а насправді перевірили свою збірку WebKit. Інструмент із власним протоколом покладається на патчі й із брендовим Safari не працює взагалі. Обіцяти замовнику «Safari покритий» на цій підставі — обіцяти те, чого немає.
Виглядає як «WebKit у CI дорівнює WebKit на маку», а насправді той самий рушій на різних ОС поводиться по-різному. Медіакодеки названі в доці поіменно; Linux-CI дока називає зазвичай найдешевшим варіантом, але найближчий до Safari досвід дає лише mac.
Виглядає як «headless — та сама збірка з прапорцем», а насправді це окремий бінарник. chromium headless shell і нове headless-ядро брендових браузерів поводяться по-різному, і дока прямо просить очікувати різницю. Тому «локально зелене, у CI червоне» — спершу підозра на різницю збірок, а вже потім на застосунок.
Виглядає як «спільний API у хелперів дає взаємозамінність», а насправді сумісність не гарантована. Контрприклад наводить сама дока: заголовки запиту є в Playwright і Puppeteer, а у WebDriver їх нема. Обіцянка звучить як «легко мігрувати», а не «працює однаково».
Виглядає як «Selenium — бібліотека для автотестів», а насправді це парасольковий проєкт, у ядрі якого WebDriver як інтерфейс, а кросбраузерність тримає стандарт W3C. Це не придирка до слів: із хибної моделі в голові беруться хибні очікування щодо сумісності.
Виглядає як недоробка інструмента, а насправді опис моделі. «Двома браузерами водночас не керує» й «тест привʼязаний до одного супердомену» стоять у переліку постійних компромісів; нативні події й обмежена робота з iframe — у переліку тимчасових. Плутати ці списки означає планувати сценарії, які не буде на чому запустити.
Виглядає як «взяли інструмент — автоматизація є», а насправді ні. Силабус формулює це без ілюзій: просте придбання інструмента успіху не гарантує.

Підсумок

Інструменти різняться моделлю, а не синтаксисом. Моделей три: wire-протокол поза процесом браузера, власний протокол інструмента, виконання всередині браузера. Усе інше — наслідки.
Мовна незалежність і віддалене виконання ростуть із wire-протоколу. Специфікація вимагає, щоб будь-який віддалений вузол був невідрізнимим від звичайного віддаленого кінця з погляду клієнта, тому той самий тест іде і на драйвер, і на ферму.
Керованість браузерів купується власними збірками. Драйверів немає, зате Chromium — не Chrome, а WebKit — не Safari; і headless тут окремий бінарник, а не .
Виконання в браузері дає прямий доступ і забирає все, що поза браузером: мову, другий браузер у сценарії, серверні бібліотеки. Інструмент називає це постійними компромісами сам.
Надбудова уніфікує API, а не поведінку. Спільний сценарний шар над різними бекендами реальний, гарантована взаємозамінність бекендів — ні.

Можливі питання

«Що обереш і чому?» — питання перевіряє не назву інструмента, а наявність критеріїв. Сильна відповідь має форму: спершу що за система під тестом і які браузери реально потрібні, потім якою мовою пише команда й який у неї досвід, потім де живе прогін — і лише тоді назва інструмента як висновок. Інтервʼюер дивиться, чи є в кандидата порядок міркування; той самий порядок радить і силабус CTAL-TAE.

«Що таке Selenium?» — питання-фільтр. Відповідь «бібліотека для автотестів» одразу видає переказ із чужих статей. Точна відповідь: парасольковий проєкт із трьох складників, у ядрі якого WebDriver як інтерфейс, а взаємозамінність коду між браузерами забезпечує специфікація W3C.

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

«Чому Cypress не може X?» — перевірка, чи розумієте ви причину, а не факт. Правильна рамка: команди виконуються всередині браузера, тому мова лишається JavaScript, двома браузерами водночас керувати не виходить, тест привʼязаний до одного супердомену, а серверні бібліотеки не імпортуються — сідінг іде через команди-містки.

«Коли доречний CodeceptJS?» — відповідь через хелпери: коли потрібен один читабельний сценарний шар над різними бекендами. І одразу назвіть межу самі: спільна API не означає гарантованої сумісності бекендів.

Якщо інструмент вам незнайомий, найкраща відповідь — назвати межу свого знання й перевести розмову на модель, яку ви розумієте. Це читається як зрілість, а вигадана деталь архітектури — як .

Джерела

Три моделі керування браузером

W3C — WebDriver Level 2 — означення WebDriver як інтерфейсу дистанційного керування з платформо- і мовно-нейтральним wire-протоколом для програм поза процесом браузера; ланцюг local end → intermediary node → endpoint node і вимога must бути невідрізнимим як чорна скринька.
Playwright — Library — поділ на бібліотеку (єдина API для запуску браузерів) і ранер (керований наскрізний прогін) як опис другої моделі.
Playwright — Browsers — браузери й системні залежності ставить сам інструмент, окремих драйверів немає; за замовчуванням це відкрита збірка Chromium, а не брендовий Chrome, і вона на версію попереду.
Cypress — Trade-offs — третя модель словами самого інструмента: команди виконуються в браузері, немає серіалізації обʼєктів і wire-протоколів, є прямий доступ до застосунку — але тестовий код виконується не в Node, і мовою лишається JavaScript.

Що модель означає на практиці

W3C — WebDriver Level 2 — вимога невідрізнимості віддаленого вузла й статус проміжного вузла-проксі як законної частини моделі: звідси «той самий тест локально і на віддаленій машині».
Cypress — Trade-offs — постійні межі третьої моделі (не універсальний автоматизатор, двома браузерами водночас не керує, тест привʼязаний до одного супердомену, cy.origin для -переходів) і поділ обмежень на постійні й тимчасові; підготовка даних через cy.exec / cy.task / cy.request.
Playwright — Browsers — браузер постачає сам інструмент своїми збірками, окремого драйвера під кожен браузер немає.
Playwright — головна сторінка — перелік мов, під які проєкт другої моделі дає офіційну бібліотеку: TypeScript, Python, .NET, Java.

Selenium: парасольковий проєкт, а не бібліотека

Selenium — Documentation (оглядова сторінка) — Selenium як umbrella project; три складники (розширення для емуляції взаємодії, сервер розподілу, інфраструктура реалізацій W3C WebDriver із взаємозамінним кодом); WebDriver у ядрі саме як interface; волонтерська природа проєкту; склад екосистеми (WebDriver, Grid, IDE, Selenium Manager, практики) і поділ практик на Encouraged / Discouraged з модальністю Consider using для fluent API.
W3C — WebDriver Level 2 — мовна нейтральність протоколу й невідрізнимість віддаленого вузла як архітектурні причини довговічності цієї моделі.

Playwright і Cypress: де саме проходить компроміс

Playwright — Browsers — три рушії плюс брендові канали; патчені Firefox і WebKit, з брендовими Firefox і Safari інструмент не працює; різниця платформ усередині того самого рушія (медіакодеки); chromium headless shell як окремий бінарник і застереження про інакшу поведінку нового headless-ядра.
Playwright — Library — ручне створення browser → context → page у бібліотеці проти лінивих вбудованих фікстур ранера; web-first assertions і матриця конфігурацій як властивості саме ранера.
Playwright — головна сторінка — свіжий контекст на кожен тест, еквівалентний новому профілю браузера, як механізм ізоляції.
Cypress — Trade-offs — прямий доступ до застосунку без серіалізації як вигода третьої моделі і власна позиція інструмента: обмеження подаються як захист від поганих, повільних і -тестів.

CodeceptJS і надбудови: один сценарій, різні бекенди

CodeceptJS — Basics — I як актор і проксі до ввімкнених хелперів; делегування всіх команд бекендам і перелік бекендів (Playwright, WebDriver через WebDriver-протокол, Puppeteer через протокол DevTools); спільний API без гарантії сумісності з контрприкладом про заголовки запиту; порада взяти один хелпер; глобальний промісний ланцюг і правило await для grab; вбудоване очікування й автоматичний ретрай невдалого кроку; два найважливіші налаштування конфігурації.
CodeceptJS — Configuration — хелпер у конфігурації задає рушій виконання, і той самий набір сценаріїв перемикається між рушіями через конфіг («the right per-helper translation … automatically»).

Критерії вибору: з чого починати відповідь

ISTQB® Certified Tester Advanced Level Test Automation Engineering (CTAL-TAE) v2.0 — §1.2.2: порядок вибору інструмента (спершу аналіз системи під тестом, потім склад і досвід команди), збіг мови інструмента з мовою системи під тестом як порада для тестувальників із навичками програмування — з названою причиною, low-code / no-code як життєздатний вибір для команди без досвіду програмування.
ISTQB® Certified Tester Foundation Level Syllabus v4.0.1 — §6.1: силабус перелічує категорії інструментів, а не конкретні бібліотеки; §6.2: застереження, що просте придбання інструмента успіху не гарантує.
MDN — Introduction to cross-browser testing — покрити всі браузери й пристрої неможливо, тож діапазон підтримки — домовленість із власником продукту; матриця будується з даних про аудиторію; браузери на спільному рушії рендерингу не потребують окремих рядків.
web.dev — Baseline (Web Platform Baseline) — базовий набір браузерів як мінімальний кістяк матриці: Chrome (десктоп і Android), Edge, Firefox (десктоп і Android), Safari (macOS та iOS).

Типові помилки

Playwright — Browsers — джерело трьох перших пасток: патчені збірки замість брендових Firefox і Safari, різниця платформ усередині рушія, chromium headless shell проти нового headless-ядра.
CodeceptJS — Basics — спільний API хелперів без гарантованої сумісності та власний контрприклад доки про заголовки запиту.
Selenium — Documentation (оглядова сторінка) — Selenium як парасольковий проєкт із WebDriver-інтерфейсом у ядрі та кросбраузерністю на стандарті W3C.
Cypress — Trade-offs — поділ обмежень на постійні (наслідок архітектури) і тимчасові (беклог) із поіменним переліком обох.
ISTQB® Certified Tester Foundation Level Syllabus v4.0.1 — §6.2: просте придбання інструмента успіху не гарантує.

Підсумок

W3C — WebDriver Level 2 — перша модель: мовно-нейтральний wire-протокол поза процесом і невідрізнимість віддаленого вузла.
Selenium — Documentation (оглядова сторінка) — Selenium як парасольковий проєкт із трьох складників і кросбраузерність на стандарті W3C.
Playwright — Library — поділ бібліотека / ранер як опис другої моделі.
Playwright — Browsers — ціна другої моделі: свої збірки браузерів, окремий headless-бінарник, різниця платформ.
Cypress — Trade-offs — третя модель і її постійні компроміси словами самого інструмента.
CodeceptJS — Basics — надбудова над моделями: делегування бекендам і спільна API без гарантії сумісності.

Можливі питання

ISTQB® Certified Tester Advanced Level Test Automation Engineering (CTAL-TAE) v2.0 — §1.2.2: порядок міркування, який і задає структуру сильної відповіді, — спершу система під тестом, потім команда.
Selenium — Documentation (оглядова сторінка) — джерельне формулювання відповіді «що таке Selenium»: парасольковий проєкт, три складники, WebDriver як інтерфейс, кросбраузерність на стандарті W3C.
Playwright — Browsers — матеріал для відповіді про різницю архітектур: власні збірки браузерів, брендові канали, межі кросбраузерності.
Playwright — головна сторінка — другий бік перевіреної негативної знахідки: Selenium на цій сторінці не згадується — як і Playwright на оглядовій сторінці Selenium, тож прямого порівняння там немає.
Cypress — Trade-offs — причини, а не факти, для питання «чому не може»: виконання в браузері, одна мова, один супердомен, команди-містки до бекенда.
CodeceptJS — Basics — відповідь про доречність надбудови й межу, яку варто назвати самому: спільна API без гарантованої сумісності бекендів.

Відео до теми

Selenium Webdriver Architecture overviewHOT testing

Как автотесты управляют браузером?росHOT testing

Обзор Selenium инструментов (IDE, Webdriver, Grid)росHOT testing

Обзор фреймворка WebdriverIOросHOT testing

Protractorjs deprecated! What to do?росHOT testing

67. Selenium IDEПопелюха 👾 Тестування ПЗ

перша мова програмування (для тестувальника)qa senpai | test automation

Донатний курсPlaywright — курс від автора каналу HOTtestingДоступ за донат на банку автора курсуДо курсу

Чим Selenium, Playwright, Cypress і CodeceptJS відрізняються один від одного?

Різниця не в тому, як записується клік, а в тому, звідки цей клік приходить у браузер. Архітектур тут три: керування ззовні через стандартизований wire-протокол, керування ззовні через власний протокол конкретного інструмента, і виконання тестового коду просто всередині браузера. Ця розвилка вирішує все прикладне: доступні мови, можливість відкрити два браузери в одному сценарії, чи побачите ви брендовий Safari, чи поїде прогін на віддалену машину без правок у тестах. CodeceptJS четвертої архітектури не додає — це сценарний шар поверх уже наявних. Тому відповідь «Playwright, бо швидший» слабка: швидкість — наслідок, а від кандидата чекають назви (browser control model) і її меж.

Що таке Selenium?

Це (umbrella project) — набір інструментів і бібліотек під однією назвою, а не одна бібліотека. Власна дока перелічує три складники: розширення, що емулюють дії користувача, сервер розподілу для масштабного виділення браузерів і реалізації специфікації W3C WebDriver, завдяки яким той самий код лишається взаємозамінним між усіма основними браузерами. У ядрі стоїть WebDriver, і дока свідомо називає його інтерфейсом для написання наборів інструкцій — не «драйвером» і не «бібліотекою». Проєкт волонтерський, код відкритий, тож за сумісність відповідають стандарт і спільнота, а не вендор із зобовʼязаннями. Відповідь «бібліотека для автотестів» чується як переказ чужих статей — і, головне, з неї виростають хибні очікування щодо кросбраузерності.

Що таке WebDriver як стандарт і чому той самий тест іде і локально, і на віддалену машину?

WebDriver — це описаний у W3C інтерфейс дистанційного керування браузером, і дві його властивості нормативні, а не «фішки реалізації»: протокол нейтральний щодо платформи й мови, а керувальна програма живе поза процесом браузера. Ланцюг вузлів у специфікації названий поіменно: мовна бібліотека на боці тесту, проміжний вузол (найчастіше чи сітка) і кінцевий вузол, реалізований самим браузером. Ключова вимога — віддалений вузол мусить бути для клієнта невідрізнимим як чорна скринька. Саме звідси й береться перенос прогону: підключення до (browser farm) міняє точку зʼєднання, а не код тестів, бо тест про існування проксі принципово не знає. Це не перевага бренду Selenium — це вимога стандарту, і будь-яка коректна реалізація її виконує.

Що входить в екосистему Selenium, крім самого WebDriver?

Офіційна дока ділить проєкт поіменно: WebDriver, Grid, IDE, Selenium Manager і окремий розділ практик. Найчастіше в кандидатів випадає саме Selenium Manager — а це важлива зміна: клопіт із розкладанням драйверів під версії браузерів переїхав усередину проєкту, і сторонні менеджери драйверів більше не обовʼязкові. Розділ практик читається уважно, бо там явний поділ на заохочені й не заохочені підходи: серед заохочених — models, незалежність тестів між собою і свіжий браузер на кожен тест. Модальність порад варто передавати точно: fluent API стоїть у формулюванні «варто розглянути», тобто це запрошення подумати, а не припис. Різниця між «рекомендовано» і «розгляньте» — саме те, на чому видно, читав кандидат джерело чи перекази.

Playwright ставить браузери сам. У чому тут виграш і яка ціна?

Виграш у тому, що окремих драйверів під кожен браузер немає взагалі: браузери й системні залежності розкладає власна CLI-команда інструмента, тож середовище відтворюється однією командою і в CI, і на новому ноутбуці. Ціна — браузери стають його браузерами. За замовчуванням підніметься не Google Chrome, а відкрита збірка Chromium, що випереджає брендовий браузер на одну версію; Firefox і WebKit тут узагалі патчені, бо інструмент покладається на власні патчі й із брендовими Firefox та Safari не працює. Для брендових Chrome і Edge є окремі канали, і саме їх треба вказувати, якщо мета — перевірити те, що стоїть у користувача. Практичний наслідок: «перевірили в трьох браузерах» треба уточнювати, у яких саме збірках, інакше звіт обіцяє більше, ніж покрито.

Колега пише в звіті «Safari покрито, тести зелені в Playwright». Що тут неточно?

Неточність в одному слові: перевірено не Safari, а свіжу патчену збірку WebKit, яку постачає сам інструмент. Із брендовим Safari цей інструмент не працює за побудовою, тож твердження про Safari нічим не підтверджене — а саме на нього спирається продакт, обіцяючи щось користувачам iPhone. Друга частина проблеми тонша: навіть той самий WebKit по-різному поводиться на різних операційних системах, і дока називає медіакодеки прямо як приклад розбіжності. Тому «WebKit у Linux-контейнері» і «WebKit на маку» — не взаємозамінні рядки матриці, хоча в конфігурації вони називаються однаково. Коректне формулювання звіту: WebKit-збірка покрита, а по брендовому Safari лишається відкритим — прогін на маку його лише зменшує (це найближчий до Safari досвід із доступних інструменту), а закривають його ручною перевіркою в самому Safari або зовнішньою фермою реальних пристроїв.

Локально в headed-режимі зелено, у CI в headless — червоно. З чого почати розбір?

Перша гіпотеза тут не «баг застосунку» і не «CI повільний», а різниця збірок. Для безголового прогону постачається окремий бінарник chromium headless shell, тобто це не та сама збірка з доданим прапорцем; окремо нове headless-ядро брендових браузерів поводиться інакше, і дока прямо просить очікувати розбіжності. Тому крок перший — прогнати той самий тест локально в headless і в CI у headed (чи з видимим відео й ) і подивитися, чи ділянка розходження ходить за режимом, а не за машиною. Якщо ходить — розбіжність збірок або рендерингу, і лікується вона фіксацією режиму, а не . Якщо не ходить — далі йдуть звичайні підозрювані CI: інша роздільність, інші шрифти, повільніша мережа, паралелізм і стан даних. Головне, чого робити не варто, — накидати очікування «щоб позеленіло», не назвавши причину: так різниця збірок перетворюється на плаваючий .

Чим бібліотека Playwright відрізняється від його ранера?

Бібліотека дає єдину API для запуску браузерів і роботи з ними, додає поверх неї керований наскрізний прогін. У бібліотеці рівні browser → context → page ви створюєте руками й по порядку, і закривати їх — обовʼязок вашого коду; забули закрити контекст — тримаєте процеси й тече памʼять. Ранер натомість сам роздає тестам ізольовані page і context серед вбудованих : створення в нього ліниве — фікстура підніметься, лише коли тест згадав її у своїх аргументах, — а закриття теж на ньому. Свіжий (browser context) на кожен тест рівносильний новому профілю, тож ізоляція коштує майже нічого: браузер не перезапускається. Ранер приносить ще дві речі, яких у бібліотеці немає: перевірки, що самі очікують і перезапускають умову, і матрицю конфігурацій в одному файлі замість правки скрипта під кожен браузер. Практичний висновок: бібліотека доречна там, де браузер лише інструмент усередині чужого процесу (скрапінг, генерація PDF, службові утиліти), а для тестів беруть ранер.

Чому Cypress не може керувати двома браузерами в одному тесті?

Бо тестовий код виконується в браузері, а не поруч із ним — і всередині одного браузера другого браузера просто немає. Важлива деталь відповіді: інструмент сам заносить цей пункт у список постійних компромісів, а не в , тобто це опис архітектури, а не обіцянка колись доробити. Поруч у тому самому списку стоїть привʼязка тесту до одного супердомену: перехід на інше вмикається окремою командою cy.origin, а не є станом за замовчуванням. Для планування це критично: сценарій «продавець запросив, покупець прийняв у своєму браузері» на цій моделі не побудуєш узагалі, і його доведеться або розрізати на два тести з передачею стану, або віддати іншому інструменту. Тому питання «чому не може» перевіряє не знання факту, а розуміння причини: кандидат, який назве модель виконання, відповість і на десяток інших «чому» без заучування.

Чому в Cypress мовою тестів лишається JavaScript?

Тому що тестовий код виконується там само, де застосунок, — у браузері, а не в Node. Браузер виконує JavaScript, отже тести пишуться на ньому або на тому, що в нього компілюється; це прямий наслідок моделі, і інструмент називає його постійним компромісом. Обмінюється це на реальну вигоду: немає серіалізації обʼєктів і немає wire-протоколу між тестом і сторінкою, тож тест дістає прямий доступ до всього, що є в застосунку, включно з внутрішнім станом, а не лише до того, що видно крізь протокол. Дзеркальна ціна виникає одразу: серверні бібліотеки в браузер не імпортуються, тож усе, що поза браузером, іде через окремі команди-містки. Для команди з накопиченою на Java чи C# ця модель відпадає на першому ж кроці — і це нормальна причина вибору, а не докір інструменту.

Як у Cypress наповнити базу перед тестом, якщо серверні бібліотеки не імпортуються?

Через команди-містки до боку, що живе в Node: cy.task виконує вашу функцію в процесі ранера, cy.exec запускає системну команду, cy.request б'є прямо в API застосунку. Тобто існує, але він не «просто імпорт клієнта бази у спек-файл» — його доводиться свідомо виставляти назовні як окрему точку входу. Практично це означає додаткову інфраструктуру: файл із задачами, обгортки над міграціями чи фабриками, іноді службовий для . У першій і другій моделях цього кроку немає: там тест живе у власному процесі й відкриває зʼєднання до бази прямо з коду тесту. Це не «гірше» — це інша ціна: за прямий доступ до застосунку платять окремим містком до всього, що поза браузером.

Cypress ділить свої обмеження на два списки. Які саме й чому це важливо для планування?

Один список — постійні компроміси, наслідок архітектури: інструмент не є універсальним автоматизатором, двома браузерами водночас не керує, тест привʼязаний до одного супердомену, мова лишається JavaScript. Другий — тимчасові обмеження, і туди йдуть нативні події й неповна робота з iframe. Різниця в тому, як їх читати: перший список — опис моделі, і планувати проти нього безглуздо; другий — беклог, який може закритися версією. Плутати ці списки дорого: команда пише в тест-плані сценарій, під який просто не існує механізму, і виявляє це на етапі реалізації. І окрема ремарка на співбесіду: сам інструмент подає свої межі як захист від поганих, повільних і — це його власна позиція, а не незалежна оцінка, і так її і варто атрибутувати, а не переказувати як факт.

Що таке CodeceptJS і хто такий обʼєкт `I` у його тестах?

Це не четверта модель, а сценарний шар над уже існуючими. Тест пишеться як лінійна послідовність дій користувача, а I — це (actor): абстракція тестувальника й водночас проксі до ввімкненого хелпера (helper). Сам актор нічого не виконує: кожну команду він делегує бекенду, а бекенди накривають перші дві моделі — Playwright із власним протоколом інструмента, Puppeteer із протоколом DevTools і WebDriver із wire-протоколом; виконання всередині браузера серед бекендів немає взагалі. Звідси й доречність інструмента: він потрібен, коли цінний єдиний читабельний сценарний рівень над різними бекендами — наприклад, сюїта має жити довше за конкретний рушій, або сценарії читають люди поза командою автоматизації. Сильна відповідь одразу називає й межу: спільний API у хелперів є, гарантованої взаємозамінності — ні.

Чому CodeceptJS-тест виглядає синхронним і коли `await` усе-таки обовʼязковий?

Виглядає синхронним, бо всі дії актора складаються в глобальний ланцюг — ранер сам вибудовує порядок, і await перед кожним кроком не потрібен. Правило, коли він потрібен, жорстке й коротке: для команд, що починаються з grab (тобто витягують значення у ваш код), і для викликів імпортованих функцій та методів page object. Забути await саме там — класична причина «значення undefined, хоча в логах крок зелений». Друга особливість того самого рівня: очікування вбудовані в самі дії, а невдалий крок повторюється автоматично — тобто тут живе нижче, ніж ретрай цілого тесту. Це зручно, але маскує повільність застосунку: крок, який тихо перепройшов з другої спроби, у звіті виглядає нормальним.

«Перемкнемо бекенд у конфізі за пʼять хвилин» — наскільки це правда для CodeceptJS?

Наполовину. Правда та, що хелпери мають спільну API, конфігурація задає рівно дві головні речі — який хелпер виконує кроки і базовий URL застосунку, а окремий пакет @codeceptjs/configure бере на себе переклад налаштувань під конкретний хелпер. Неправда — що поведінка збережеться: джерело саме пише, що через відмінності бекендів сумісність не гарантована, і наводить власний контрприклад — заголовки запиту ставляться в Playwright і Puppeteer, а у WebDriver ні. Тому порада в доці сформульована як вибір: узяти один хелпер і мігрувати тоді, коли зміняться вимоги, а не тримати два «на всяк випадок». Практично міграцію перевіряють прогоном, а не читанням конфіга: спершу вузький на новому бекенді, потім повна сюїта, і окремо — усі місця, де тест ліз у мережу, файли чи нативні діалоги. Обіцяти замовнику «працює однаково на будь-якому бекенді» на цій підставі не можна; чесне формулювання — «мігрувати дешево».

Чим Playwright архітектурно відрізняється від Selenium?

Головна різниця — хто відповідає за сумісність із браузерами. У Selenium це стандарт: код спирається на специфікацію W3C WebDriver, керування йде поза процесом браузера через мовно-нейтральний протокол, а браузер у системі вже стоїть свій, до нього лише додається драйвер. У Playwright це сам інструмент: власний протокол, власні збірки браузерів, які він же й розкладає, і офіційні бібліотеки під обмежений набір мов — TypeScript, Python, .NET, Java. Звідси й наслідки в обидва боки: у першого — будь-яка мова клієнта й віддалене виконання, вбудоване в модель; у другого — керованість, ізоляція контекстами майже безкоштовно й відтворюване середовище, але Chromium замість Chrome і WebKit замість Safari. Окрема дисциплінарна деталь: на оглядових сторінках обох проєктів прямого порівняння немає — жодна не згадує іншу, тож заявляти «швидший у два рази» без власних чисел і опису методики — типовий провал. Правильний тон відповіді — «різні моделі з різними цінами», а не «один кращий».

«Що обереш і чому?» — як побудувати сильну відповідь?

Це питання не про назву інструмента, а про наявність порядку міркування, і порядок цей у силабусі CTAL-TAE названий прямо: спершу аналіз системи під тестом, і лише потім склад та досвід команди. Тому сильна відповідь ідеться по кроках: що це за застосунок і які браузери реально потрібні його аудиторії; якою мовою пише команда й наскільки вона взагалі програмує; де живе прогін — локально, у CI, на віддалених браузерах; і аж тоді назва інструмента як висновок із перерахованого. Два аргументи звідти ж добре звучать на інтервʼю: збіг мови інструмента з мовою застосунку — плюс, бо дає спільний дебаг із розробниками й перехресне навчання; а для команди без досвіду програмування low-code-рішення силабус називає життєздатним вибором, не «поразкою». Останній крок відповіді — перевірка на заборони моделі: якщо в сценаріях потрібні два браузери водночас або брендовий Safari, вибір відсікається не смаком, а архітектурою. І варто окремо сказати, чого інструмент не вирішує: сам факт придбання інструмента успіху не гарантує — це формулювання CTFL, і воно закриває найпоширенішу управлінську ілюзію.

Як формується матриця браузерів і де в ній видно межі інструментів?

Матриця будується з даних про аудиторію продукту, а не з уподобань команди, і сам діапазон підтримки — це домовленість із власником продукту, бо покрити всі браузери й пристрої фізично неможливо. Далі працює економія: браузери на спільному (Chrome, Edge, Opera) для більшості перевірок верстки не потребують окремих рядків — досить одного представника. А от Safari потребує свого рядка, бо рушій інший, — і саме тут проступають межі другої й третьої моделей: одна дає патчену WebKit-збірку замість брендового Safari, друга взагалі виконується всередині одного браузера. Мінімальний кістяк для продукту без особливих вимог дає базовий набір Baseline: Chrome (десктоп і Android), Edge, Firefox (десктоп і Android), Safari (macOS та iOS). Практичний висновок: матрицю узгоджують до вибору інструмента, інакше інструмент тихо визначає її замість продакта.

У вакансії згадано інструмент, якого ви не знаєте (наприклад, WebdriverIO). Що відповідати?

Назвати межу свого знання прямо й перевести розмову на модель, яку ви розумієте. Формулювання на кшталт «із ним не працював, тому внутрішню будову вигадувати не буду; за назвою це шар над браузерною автоматизацією, і перше, що я б зʼясував, — на якій моделі керування він стоїть і чи є в ньому власні збірки браузерів» читається як зрілість, а не як провал. Причина проста: вигадана деталь архітектури — найшвидший спосіб втратити довіру інтервʼюера, бо перевіряється вона одним уточнювальним питанням, а решта відповідей після цього переслуховується з підозрою. Дальший хід — показати перенос: якщо ви розумієте три моделі та їхні ціни, ви знаєте, які саме питання поставити до незнайомого інструмента, і це цінніше за перелік його команд. І цілком нормально додати, за який час ви очікуєте його освоїти й на що спиратиметеся — доку, наявні тести проєкту, схожий досвід.

Три кейси, у яких вибір вирішує долю проєкту, а не смак команди: розбір трьох брифів за , чесне читання конфігурації Playwright, коли продакт хоче почути «Safari покрито», і перевірка обіцянки «перемкнемо бекенд CodeceptJS за пʼять хвилин». Скрізь — на що дивитися і чому.

Кейс 1. Три брифи й таблиця рішень

Питання «що обереш і чому» на співбесіді й на реальному кікоффі має однакову форму: спочатку вхідні дані, потім відсічення за моделями, і лише тоді назва. Порядок міркування беремо з силабуса CTAL-TAE — спершу система під тестом, потім команда.

Бріф А. Внутрішній портал банку. Аудиторія — співробітники на корпоративних Windows-машинах із Chrome і Edge. Є десять років на Java, четверо автоматизаторів, які пишуть на Java, і власна сітка віддалених браузерів у датацентрі. Треба додати нового модуля.

Бріф Б. SaaS-продукт для дизайнерів. Половина трафіку — Safari на macOS та iOS. Команда — три фронтендери на TypeScript і один AQA, тестів майже немає, потрібен швидкий старт із нормальним дебагом і CI.

Бріф В. Аутсорс-проєкт, замовник хоче, щоб сценарії читав його бізнес-аналітик. Технічно це той самий вебзастосунок, але через рік прогін, можливо, переїде з локальних браузерів на хмарну ферму — а може, й ні.

Крок міркування	Бріф А	Бріф Б	Бріф В
Система під тестом	внутрішній портал, один рушій рендерингу	публічний SaaS, критичний Safari	звичайний вебзастосунок, вимога — читабельність
Реально потрібні браузери	Chrome + Edge	Chromium, Firefox, WebKit і брендовий Safari	Chrome, далі за домовленістю
Мова й досвід команди	Java, накопичена сюїта	TypeScript, той самий стек, що продукт	TS/JS, читач — не інженер
Де живе прогін	власна віддалена сітка	CI, локальні браузери інструмента	локально зараз, ферма — можливо
Що відсікає модель	нічого критичного	брендовий Safari недосяжний у другій моделі	невідомий майбутній бекенд
Висновок	`wire`-протокол: сюїту не переписуємо, прогін уже віддалений	власний протокол для щоденного прогону + окремий канал для брендового Safari	сценарний шар над одним хелпером, з наперед знаною межею

Що дивитися і чому:

У брифі А вибір роблять накопичені активи, а не порівняння фіч. Мовна нейтральність протоколу означає, що сюїта на Java лишається валідною, а віддалена сітка вже працює як проміжний вузол — переїзд між машинами тут міняє точку підключення, не тести. Пропозиція «переписати все на новому інструменті» тут коштує роки й не купує нічого, чого немає.
У брифі Б рішення двоскладове, і саме це ознака зрілої відповіді. Друга модель дає збіг мови з продуктом (спільний дебаг із фронтендерами — названий у силабусі аргумент за) і дешеву ізоляцію контекстами. Але брендовий Safari вона не покриває взагалі, тож у плані мусить бути окремий рядок: мак у прогоні, зовнішня ферма реальних пристроїв або узгоджена з продактом ручна перевірка. Одним інструментом тут не закривається — і це не привід від нього відмовлятися.
У брифі В головна вимога не технічна, а комунікаційна. Сценарний шар над хелпером дає читабельність, але обіцяти замовнику «бекенд перемкнемо будь-коли» не можна: спільна API не гарантує однакової поведінки. Чесна фраза для кікоффу — «мігрувати дешево», а не «працює однаково».
Що не є аргументом на жодному з трьох брифів. «Модно», «у статті написано, що швидший», «у нас уже є ліцензія». Силабус CTFL формулює межу прямо: сам факт придбання інструмента успіху не гарантує — тож і рішення обґрунтовується вхідними даними, а не володінням інструментом.

Кейс 2. Читаємо конфігурацію Playwright так, як її прочитає продакт

Продакт питає: «Safari покрито?» У конфігурації є проєкт із назвою webkit, тести зелені. Формально відповісти «так» легко, і саме тут зʼявляється обіцянка, якої немає чим підтвердити.

// playwright.config.ts — те, що бачить продакт, і те, що це насправді означає
import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
  projects: [
    // власна відкрита збірка Chromium, а не брендовий Chrome користувача
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
    // патчена збірка WebKit; брендовий Safari цим проєктом не запускається
    { name: 'webkit', use: { ...devices['Desktop Safari'] } },
    // а ось це вже брендовий браузер: окремий канал, не окремий рушій
    { name: 'chrome-branded', use: { channel: 'chrome' } },
    // мобільний профіль — емуляція розмірів і UA, той самий рушій
    { name: 'mobile-safari', use: { ...devices['iPhone 15'] } },
  ],
});

Що дивитися і чому:

Назва проєкту й назва профілю пристрою — не те саме, що назва браузера. Профіль Desktop Safari запускає патчену WebKit-збірку інструмента; з брендовим Safari цей інструмент не працює, бо покладається на власні патчі. Тому рядок звіту «Safari — pass» технічно неправдивий, а помітять це вже після релізу, по репортах користувачів iPhone.
channel: 'chrome' — єдиний рядок у цьому файлі, який справді запускає брендовий браузер. Якщо в матриці узгоджено «Chrome, який стоїть у користувача», то без каналу перевіряється Chromium, до того ж на версію попереду брендового. Для більшості перевірок верстки різниця неважлива, але це інша збірка й інша версія — тож домовленість про брендовий Chrome без каналу просто не виконана.
iPhone 15 у переліку пристроїв — це емуляція, не пристрій. Розмір вікна, User-Agent і тач-події підставляються, рушій лишається той самий, а операційна система — та, на якій іде прогін. Обіцяти «протестовано на iPhone» на цій підставі не можна; коректне формулювання — «перевірено мобільний вʼюпорт».
Той самий проєкт webkit дасть різні результати в Linux- й на маку. Дока називає медіакодеки прямо як приклад платформної розбіжності всередині одного рушія, тож Linux-CI — найдешевший варіант, але найближчий до Safari досвід дає лише мак.

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

Покрито автотестами:  Chromium (власна збірка), брендовий Chrome (channel), WebKit-збірка на Linux
Емуляція вʼюпортів:   iPhone 15 (проєкт mobile-safari) — розміри й UA, рушій той самий
НЕ покрито:           брендовий Safari (macOS, iOS) — недосяжний для цього інструмента
Закривається:         прогін webkit на mac-ранері + ручна перевірка ключових флоу в Safari

Кейс 3. «Перемкнемо бекенд у конфізі» — перевіряємо обіцянку

Проєкт на CodeceptJS із хелпером WebDriver. Команда хоче перейти на Playwright і планує це як зміну кількох рядків у конфігурації. Технічно так і є — і саме тому варто перевірити, що зміниться в поведінці.

// codecept.conf.js — два головні налаштування: який хелпер виконує і базовий URL
exports.config = {
  helpers: {
    // було: WebDriver — wire-протокол, окремий драйвер
    // стало: Playwright — власний протокол інструмента, свої збірки браузерів
    Playwright: {
      url: 'https://app.example.com',
      show: false,
      browser: 'chromium',
    },
  },
  tests: './tests/**/*_test.js',
};

Сам сценарій справді не змінюється — делегує кроки новому хелперу:

Scenario('гість бачить кнопку входу', ({ I }) => {
  I.amOnPage('/login');
  I.see('Увійти', 'button');
});

А ось цей сценарій на попередньому бекенді працювати не мав узагалі — і це рівно той контрприклад, який наводить сама дока:

// заголовки запиту ставляться в Playwright і Puppeteer, у WebDriver — ні
Scenario('фіча-флаг приходить заголовком', ({ I }) => {
  I.haveRequestHeaders({ 'X-Feature-Flag': 'new-checkout' });
  I.amOnPage('/checkout');
  I.see('Новий чекаут');
});

Що дивитися і чому:

Спільна API — не гарантія сумісності, і джерело каже це прямо. Через відмінності бекендів частина команд є не всюди; заголовки запиту — названий у доці приклад, і він же найчастіший у реальних сюїтах, бо через нього ганяють й тестові ознаки. Тому міграцію перевіряють прогоном, а не читанням конфігурації.
Порядок перевірки — від вузького до повного. Спершу на десяток сценаріїв на новому хелпері, потім повна сюїта, і окремо ревʼю всіх місць, де тест ліз поза сторінку: мережа, файли, нативні діалоги, кілька вкладок. Саме там межі бекендів розходяться найсильніше.
Дока радить один хелпер, а не два «на всяк випадок». Тримати сюїту сумісною одразу з двома бекендами означає постійно писати за найменшим спільним знаменником і платити за це подвійним прогоном у CI. Міграція — подія під зміну вимог, а не режим життя проєкту.
Автоматичний кроку тут працює проти діагностики міграції. Невдалий крок повторюється сам, тож частина розбіжностей між бекендами не почервоніє, а лише сховається за другою спробою й повільнішим прогоном. Під час міграції корисно дивитися не тільки на статус, а й на час кроків: раптове зростання — сигнал, що крок доходить із ретраю.
Окремо тримайте в голові рівень await. Тест виглядає синхронним завдяки глобальному ланцюгу, але grab-команди й виклики методів чекати обовʼязково. Після зміни бекенда пропущений await виявляється охочіше: значення приходить із іншою швидкістю, і undefined перестає бути «стабільно зеленим».

Три моделі керування браузером

Можу назвати три (browser control model) і сказати, що інструменти різняться саме ними, а не набором команд.
Можу за чотирма осями розкласти будь-який із цих інструментів: мова тесту, де живе тестовий код, хто постачає браузер, чи є прямий доступ до бази з тесту.

`wire`-протокол і Selenium

Знаю, що WebDriver стандартизований у W3C і що мовна нейтральність із роботою поза процесом браузера — нормативні властивості, а не фішки реалізації.
Можу назвати ланцюг вузлів специфікації (мовна бібліотека на боці тесту → проміжний вузол- або сітка → кінцевий вузол у самому браузері) і вимогу невідрізнимості віддаленого вузла — і чому саме з неї, а не з фіч інструмента, випливає перенос прогону на (browser farm) без правок у тестах.
Можу відповісти на питання-фільтр «що таке Selenium»: (umbrella project) із трьох складників, у ядрі — WebDriver як інтерфейс, кросбраузерність тримає стандарт W3C, а не вендор.
Знаю склад екосистеми поіменно (WebDriver, Grid, IDE, Selenium Manager, розділ практик), що керування драйверами тепер частина самого проєкту, і вмію точно передавати модальність практик: свіжий браузер на тест і незалежність тестів — заохочені, fluent API — «варто розглянути», а не припис.

Власний протокол: Playwright

Розумію, за що платить друга модель: окремих драйверів немає, зате браузери власні — Chromium замість брендового Chrome, і на версію попереду.
Знаю різницю «перевірили Safari» vs «перевірили патчену збірку WebKit», а також те, що той самий рушій на різних ОС поводиться по-різному (медіакодеки — названий у доці приклад), тож WebKit у Linux-CI і WebKit на маку — не один рядок матриці.
Можу пояснити різницю бібліотека vs : у бібліотеці browser → context → page створюю й закриваю руками, ранер віддає ізольовані ліниво й закриває сам, а свіжий (browser context) на тест еквівалентний новому профілю — тому ізоляція майже без накладних витрат.
Розумію, що безголовий режим — це окремий бінарник, а не до тієї самої збірки, тож «локально зелене, у CI червоне» спершу перевіряю як різницю збірок.

Виконання в браузері: Cypress

Можу пояснити вигоду третьої моделі (немає серіалізації обʼєктів і wire-протоколу, тест бачить внутрішній стан застосунку напряму) і її дзеркальну ціну: мовою назавжди лишається JavaScript, двома браузерами водночас керувати не виходить, тест привʼязаний до одного супердомену (cy.origin — окрема команда, не стан за замовчуванням).
Не плутаю два списки обмежень: постійні компроміси — опис архітектури, тимчасові (нативні події, робота з iframe) — ; і памʼятаю, що «обмеження як захист від флакі-тестів» — формулювання самого інструмента, а не незалежна оцінка.
Можу назвати команди-містки для підготовки даних (cy.task, cy.exec, cy.request) і пояснити, чому бази доводиться виставляти назовні окремо.

Надбудови: CodeceptJS

Розумію, чому CodeceptJS не є четвертою моделлю: це сценарний шар, у якому I — (actor), тобто абстракція користувача й проксі до ввімкненого хелпера (helper); кроки виконують бекенди — Playwright (власний протокол), WebDriver (wire-протокол) і Puppeteer (протокол DevTools), тож накриті лише перші дві моделі.
Розумію головний компроміс надбудови: спільний API у хелперів є, гарантованої сумісності немає — контрприклад доки про заголовки запиту у WebDriver знаю поіменно.
Знаю правило await (тест виглядає синхронним через глобальний ланцюг, але grab-команди, імпортовані функції та методи чекати обовʼязково) і памʼятаю, що невдалий крок повторюється автоматично — тут живе нижче за ретрай тесту й маскує повільність застосунку у звіті.

Вибір інструмента й матриця браузерів

Знаю порядок міркування з CTAL-TAE: спершу аналіз системи під тестом, потім склад і досвід команди — і вмію відповідати «що обереш» саме цією послідовністю, включно з аргументом про збіг мови інструмента з мовою застосунку (спільний дебаг із розробниками й перехресне навчання).
Розумію, що діапазон підтримки браузерів — домовленість із власником продукту, а матриця будується з даних про аудиторію, не з уподобань команди; знаю, чому Chrome, Edge і Opera зазвичай не потребують окремих рядків, а Safari потребує — і де тут проходять межі другої й третьої моделей.
Памʼятаю застереження CTFL: сам факт придбання інструмента успіху не гарантує, а силабус говорить про категорії інструментів, не про конкретні бібліотеки.
Можу назвати межу свого знання про незнайомий інструмент замість вигаданої архітектури — і перевести розмову на модель, яку розумію.

Знайшли помилку?

Ландшафт інструментів: Selenium, Playwright, Cypress, CodeceptJS

Три моделі керування браузером

Що модель означає на практиці

Selenium: парасольковий проєкт, а не бібліотека

Playwright і Cypress: де саме проходить компроміс

CodeceptJS і надбудови: один сценарій, різні бекенди

Критерії вибору: з чого починати відповідь

Типові помилки

Підсумок

Можливі питання

Джерела

Чим Selenium, Playwright, Cypress і CodeceptJS відрізняються один від одного?

Що таке Selenium?

Що таке WebDriver як стандарт і чому той самий тест іде і локально, і на віддалену машину?

Що входить в екосистему Selenium, крім самого WebDriver?

Playwright ставить браузери сам. У чому тут виграш і яка ціна?

Колега пише в звіті «Safari покрито, тести зелені в Playwright». Що тут неточно?

Локально в headed-режимі зелено, у CI в headless — червоно. З чого почати розбір?

Чим бібліотека Playwright відрізняється від його ранера?

Чому Cypress не може керувати двома браузерами в одному тесті?

Чому в Cypress мовою тестів лишається JavaScript?

Як у Cypress наповнити базу перед тестом, якщо серверні бібліотеки не імпортуються?

Cypress ділить свої обмеження на два списки. Які саме й чому це важливо для планування?

Що таке CodeceptJS і хто такий обʼєкт I у його тестах?

Чому CodeceptJS-тест виглядає синхронним і коли await усе-таки обовʼязковий?

«Перемкнемо бекенд у конфізі за пʼять хвилин» — наскільки це правда для CodeceptJS?

Чим Playwright архітектурно відрізняється від Selenium?

«Що обереш і чому?» — як побудувати сильну відповідь?

Як формується матриця браузерів і де в ній видно межі інструментів?

У вакансії згадано інструмент, якого ви не знаєте (наприклад, WebdriverIO). Що відповідати?

Кейс 1. Три брифи й таблиця рішень

Кейс 2. Читаємо конфігурацію Playwright так, як її прочитає продакт

Кейс 3. «Перемкнемо бекенд у конфізі» — перевіряємо обіцянку

Три моделі керування браузером

wire-протокол і Selenium

Власний протокол: Playwright

Виконання в браузері: Cypress

Надбудови: CodeceptJS

Вибір інструмента й матриця браузерів

Що таке CodeceptJS і хто такий обʼєкт `I` у його тестах?

Чому CodeceptJS-тест виглядає синхронним і коли `await` усе-таки обовʼязковий?

`wire`-протокол і Selenium