Playwright для QA-інженерів

Пояснити дві причини збоїв попередньої UI-автоматизації — нестабільність через таймінг і накладні витрати на драйвери — і як архітектура Playwright усуває кожну

Читати й писати конструкції JavaScript, які трапляються в кожному тесті Playwright: const/let, стрілкові функції, шаблонні рядки, деструктуризацію, об'єкти та масиви

Встановити Playwright у новий репозиторій і в наявний фронтенд-репозиторій, не зламавши жодного з них

Запускати з командного рядка весь набір, теку, файл, окремий тест, проєкт, останні тести, що впали, і лише тести, яких торкнулася зміна

Структурувати spec-файл блоками describe і чотирма хуками та сказати, коли кожен хук виконується відносно воркерів

Читати словник DOM, від якого залежить локатор: тег, атрибут, клас, id, текстовий вузол, батьківський і дочірній елемент

Застосовувати порядок пріоритету локаторів: роль, мітка, плейсхолдер, текст, alt, title, test id, CSS або XPath — в останню чергу

Використовувати filter() з hasText, hasNotText, has, hasNot і visible, щоб звузити набір за вмістом, за нащадком або за видимістю

Відрізняти web-first асерти від звичайних і за замовчуванням вибирати перші

Перелічити перевірки готовності до дії та пояснити, яка дія потребує яких із них

Вибирати між fill, clear і pressSequentially за подіями, які надсилає кожен із них, і казати, коли потрібне посимвольне введення

Правильно використовувати check, uncheck і setChecked та обґрунтовувати force: true для візуально прихованого нативного input

Пояснити, що Playwright робить із нативним діалогом, коли слухача не зареєстровано, і що зобов'язаний зробити зареєстрований слухач

Автоматизувати поле вибору дати введенням із клавіатури, де це можливо, і навігацією календарем, де ні

Назвати конкретне дублювання, яке усуває page object, і конкретну зміну, яку він робить дешевою

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

Назвати вбудовані фікстури й сказати, що дає кожна, і пояснити, звідки береться testInfo (це не фікстура)

Використовувати проєкти, щоб запускати ті самі тести в різних браузерах, на пристроях, під ролями та в оточеннях ENGAGE, і обмежувати паралельність проєкту його власним налаштуванням workers

Побудувати setup-проєкт, який один раз проходить автентифікацію й зберігає сесію в storageState, зокрема IndexedDB, коли бібліотека ідентифікації зберігає токени там

Робити скриншоти сторінки, елемента та в буфер і додавати їх до звіту

Писати порівняння скриншотів за допомогою toHaveScreenshot і керувати еталонами через режими updateSnapshots і шаблони шляхів

Використовувати фікстуру request для написання API-тестів, перевіряючи через await expect(response).toBeOK(), а також заголовки й тіло

Вибирати між fulfill, continue, abort і fallback для перехопленого запиту й пояснювати порядок обробників

Пояснити, що таке воркер, як робота розподіляється з fullyParallel і без нього та яка кількість воркерів за замовчуванням

Запускати набір в офіційному образі Playwright із рекомендованими прапорцями Docker і тримати тег образу рівним встановленій версії Playwright

Розводити пари понять Playwright, які найчастіше плутають, називаючи одне правило, що розділяє кожну пару

Вирішувати, що автоматизувати і на якому рівні — модульні тести, API, UI, візуальні перевірки, доступність, користувацькі сценарії — і обстоювати це рішення перед клієнтом