Playwright
Playwright — це бібліотека автоматизації браузера й раннер тестів, що керує Chromium, Firefox і WebKit через один API. Майже все, за що його люблять, — що тести чекають на сторінку, а не змагаються з нею, що падіння приходить із трасою для відтворення, що пʼятдесят кейсів ідуть паралельно на ноутбуці, — є наслідком одного архітектурного рішення, а не списком можливостей. Ця сторінка пояснює те рішення, що воно дає і де інструмент справді не допомагає.
- Тест виконується
- Поза браузером
- Одиниця ізоляції
- Контекст браузера
- Чекає за
- Перевірками готовності
Архітектура і є списком можливостей
Ваш тест виконується у власному процесі. Він відкриває одне постійне зʼєднання з браузером, який сам запустив, і кожна інструкція та кожна подія йдуть цим зʼєднанням. Це весь задум, і його варто зрозуміти до будь-якого API, бо кожна відома властивість інструмента виявляється наслідком саме цього, а не окремою інженерною роботою.
Оскільки драйвер бачить стан браузера напряму, а не крізь сторінку, він може оглянути елемент перед дією й почекати, доки дія матиме сенс. Оскільки все йде одним дротом, увесь запуск можна записати й відтворити пізніше. І оскільки одиницею ізоляції є контекст браузера — приватна банка cookie та сховище всередині вже запущеного браузера, — чиста сесія коштує мілісекунди, а не запуск браузера, і саме це робить справжню паралельність доступною.
Автоочікування — і чому воно прибирає більшість нестабільності
Найбільша окрема причина ненадійних браузерних тестів — дія тесту до готовності застосунку: кнопка вже є в DOM, але ще накрита оверлеєм завантаження, або вона в русі анімації, або React відрендерив її, але ще не привʼязав обробник. Старіші інструменти відповідали на це паузами й ручними очікуваннями, тобто здогадкою в одязі коду. Playwright відповідає перевіркою перед кожною дією: чи елемент у стані, у якому дія має сенс.
| Перевірка перед дією | Що це запобігає |
|---|---|
| Елемент прикріплений до DOM | Дії над вузлом, який перерендер уже замінив, — класичне падіння на застарілому елементі. |
| Він видимий | Клік по чомусь нульового розміру чи схованому за згорнутою панеллю: тихо проходить і нічого не робить. |
| Він стабільний — не рухається між кадрами | Клік під час анімації, що влучає туди, де кнопка була, а не де вона є. |
| Він приймає події — його ніщо не перекриває | Клік по оверлею модалки замість кнопки під ним — і падіння через три кроки з незрозумілої причини. |
| Він увімкнений | Надсилання форми, поки кнопка ще вимкнена валідацією, що не завершилася. |
Друга половина моделі — локатор. Локатор не є елементом: це опис того, як його знайти, і він розвʼязується заново щоразу при використанні. Саме ця відмінність робить наведені перевірки можливими на сторінці, що перерендерюється під вами: той самий локатор знаходить поточний елемент, а не тримає посилання на вузол, якого вже немає. Перевірки працюють так само — повторюються, доки умова не виконається або не спливе тайм-аут, — і тому перевірка тексту, що приходить після мережевої відповіді, не потребує жодного очікування навколо.
Ізоляція, фікстури та як завершити набір за хвилини
Кожен тест за замовчуванням отримує свіжий контекст браузера, тож немає спільних cookie, немає залишків локального сховища й немає залежності від порядку між кейсами. Це тиха причина, чому написані тут набори лишаються стабільними, коли ростуть: найчастіше джерело «окремо проходить, у наборі падає» прибрано типовою поведінкою, а не дисципліною.
Увійти раз, використати всюди
Автентифікуйтеся в кроці підготовки, збережіть стан сховища у файл — і кожен тест починається вже залогіненим. Прибирає найповільніші й найчастіше повторювані пʼять секунд у наборі.
Фікстури замість коду підготовки
Фікстура — це названа річ, яку тест просить: залогінена сторінка, засіяне замовлення, API-клієнт. Її будують на вимогу й прибирають після, тож тести оголошують потрібне, а не облаштовують його.
Воркери, а не потоки
Файли йдуть паралельно у воркер-процесах, кожен зі своїм браузером. Практична межа — зазвичай ваші тестові дані, а не процесор.
Шардинг між машинами
Той самий набір ділиться між машинами CI за індексом, а звіти потім зливаються. Саме так сорокахвилинний набір стає восьмихвилинним, нічого не видаляючи.
Дві можливості поза браузером варто знати, бо вони змінюють те, що взагалі належить набору. Playwright може робити API-запити напряму, у тому самому тесті й із тією самою сесією, — тож кейс може створити свої дані через API за пʼятдесят мілісекунд і потім перевірити одну річ в інтерфейсі, замість клікати чотири екрани, щоб дійти до потрібного стану. І він може перехоплювати мережевий трафік, тож третю сторону, яка повільна, обмежена лімітами чи недоступна в CI, можна замінити на межі, не чіпаючи код застосунку.
Що ввімкнути, щоб падіння в CI можна було діагностувати
Дорога частина наскрізного падіння — ніколи не саме падіння, а година спроб відтворити його на ноутбуці, де воно не стається. Відповідь на це — траса, і це та єдина налаштування, яку варто зробити правильно раніше за все інше.
- Записуйте трасу на першому повторі в CI. Вона фіксує знімок DOM до й після кожної дії, мережевий лог, консоль і відео та відкривається як інтерактивна шкала часу, яку ви проходите локально.
- Тримайте повтори на одиниці, а не на трьох. Один повтор плюс траса каже, чи падіння справжнє; три повтори не кажуть нічого й перетворюють справжній плаваючий баг на зелений запуск.
- Користуйтеся режимом спостереження й інспекції під час написання тестів: запуск ставиться на паузу, локатор під курсором підсвічується, і можна спробувати інший на живій сторінці.
- Ставтеся до згенерованого коду як до чернетки. Запис сценарію швидко дає робочі селектори, і вони майже завжди крихкіші за ті, які ви обрали б свідомо.
Де він не допомагає і як порівнюється
Playwright — розумний вибір за замовчуванням для нових наборів браузерних тестів у 2026 році, а значення за замовчуванням заслуговують, щоб їхні застереження назвали прямо, а не виявили на третій місяць.
- WebKit не є Safari. Це той самий рушій, але без браузера Apple навколо, тож він ловить різницю в рендерингу та API, але не все, що специфічне для випущеної збірки Safari.
- Мобільна емуляція — це вʼюпорт, user agent і тач, а не справжній пристрій. Вона знаходить проблеми верстки й не знайде бага справжнього мобільного браузера чи нативного застосунку.
- Він не тестує нативні десктопні чи мобільні застосунки й не є інструментом навантажувального тестування, хай яку спокусу становлять сто паралельних контекстів.
- Він робить нестабільні тести менш імовірними, але не робить добрим погано обраний набір. Чотириста наскрізних кейсів тут хибні рівно з тих самих причин, що й будь-де.
Обирайте Playwright, коли
- Ви починаєте набір зараз і жодне обмеження не штовхає вас до іншого.
- Вам потрібні кілька ізольованих користувачів, кілька доменів чи кілька вкладок в одному тесті.
- Важливий час набору: паралельність на контекстах дешева, а шардинг вбудований.
- Ви хочете, щоб падіння в CI можна було діагностувати без відтворення.
Дивіться в інший бік, коли
- Ваша команда пише тести на Java, C# чи Ruby й хоче першокласної підтримки — цю ділянку покриває Selenium.
- Треба ганяти справжні випущені Safari, Edge і старіші браузери на грид-фермі пристроїв.
- У команди вже є великий робочий набір на Cypress: вартість міграції зазвичай перевищує виграш.
- Те, що треба протестувати, — нативний застосунок, десктопний клієнт чи поведінка рівня системи.
Антипатерни, які варто назвати
- Додавати явні очікування «про всяк випадок» поверх автоочікування: це сповільнює набір і ховає справжнє питання часу.
- Обирати за CSS-класом чи позицією в DOM, бо так згенерував рекордер: кожен редизайн перетворюється на день ремонту тестів.
- Перевикористовувати один контекст між тестами заради часу: так повертається залежність від порядку, яку інструмент і мав прибрати.
- Підвищувати кількість повторів, доки пайплайн не позеленіє: справжні плаваючі дефекти так стають успішними запусками.
- Переносити юніт-логіку в браузерні тести, бо інструмент приємний: це найдорожчий спосіб бути ретельним.
Коли це застосовувати
Застосовуйте, коли
- Новий браузерний набір, де важать і надійність, і час виконання, і немає обмежень щодо мови.
- Тести, де в одному кейсі більше ніж один користувач, більше ніж один домен чи більше ніж одна вкладка.
- Набори, що мають запускатися на кожен мердж — із воркерами локально й шардингом між машинами CI.
- Скрізь, де важить покриття різних рушіїв і Chromium, Firefox та WebKit мають запускатися з того самого файлу тестів.
Уникайте, коли
- Як доказ, що сторінка працює у справжньому випущеному Safari чи справжньому мобільному браузері: емуляція цього не покриває.
- Для нативних десктопних чи мобільних застосунків або як інструмент навантажувального тестування.
- Як привід нарощувати наскрізний набір: приємний інструмент не змінює того, що належить цьому рівню.
- Як ціль міграції для великого робочого набору в іншому інструменті: вартість зазвичай перевищує вигоду.
Було корисно?
Поділіться з тим, хто працює над тією ж задачею.