Імплементація UI тестування із Playwright

Для UI тестування Playwright пропонує інструмент візуального порівняння зі своєї бібліотеки expect’ів — await expect(page).toHaveScreenshot(). Цей інструмент генерує так званий “golden screenshot”, тобто скріншот-ідеал, із яким він надалі порівнюватиме свої подальші скріншоти. Саме тому важливо перевірити зроблені скріншоти і пересвідчитись, що вони дійсно відображають очікуваний стан.

Варто зазначити, що в expect замість page може бути переданий будь-який плейврайтівський локатор — тоді уся зона діяльності обмежиться “коробкою” цього елементу.

В метод toHaveScreenshot() можна і навіть слід передавати кастомну назву файлу — під такою назвою із додатковою частиною, що позначає тестувальне середовище, і буде створено скріншоти. Для прикладу, await expect(page).toHaveScreenshot('blog-article.png') створить в каталозі власного тесту відповідну теку із файлами:

Якщо з якихось причин ідеальні скріншоти треба оновити, це можна зробити або через видалення відповідних снепшотів з проєкту, або через додатковий параметр --update-snapshots в консольній команді запуску тестів: npx playwright test --update-snapshots

Метод toHaveScreenshot() має низку корисних опціональних параметрів. Найуживанішим напевне буде fullPage: true, який замість скріншоту того, що наразі видно в умовному viewport браузеру, робить скріншот усієї осяжної сторінки. Але у сучасних сайтів із цим параметром велика і насичена історія різноманітних проблем. Справа в тім, що сучасні сайти є багатофункціональними та інтерактивними веб-застосунками: вони реагують на скролл, програють анімації, адаптують сторінку, мають “липкі” елементи тощо. Все це реагує на певні дії користувача, які Playwright у захваті всієї сторінки не відтворить.

Але є і хороша новина: ми самі можемо спробувати їх підібрати та відтворити перед тим, як робити скріншот. В нагоді нам стане метод page.evaluate(), який по суті дозволить в суто Playwright фреймворк засунути кастомні методі роботи зі сторінкою. Скажімо, ми хочемо проскроллити сторінку до самого кінця. Робити це “природнім чином”, тобто не телепортуватися у обчислений крайній координат сторінки, а саме що доскроллитися до нього, щоби всі елементи на сторінці, підв’язані під переміщення користувача, мали змогу відпрацювати. 

Одне з найбільш популярних рішень цієї задачі виглядає так:

Що тут відбувається? Під проміс ми ховаємо вище названий page.evaluate(), в межах якого знаходиться ще один проміс, який працює з часовими інтервалами. Метод setInterval() приймає в себе функцію, яку він виконуватиме за розкладом із вказаною періодичністю, що в нашому випадку є 100мс. В нас також присутня умова виходу із цього циклу, за якою ми негайно припиняємо скролл, коли поточна відмітка висоти перевищує або дорівнює висоті усієї сторінки.

Два параметри, які ми тут можемо конфігурувати під себе — це distance та параметр delay в методі setInterval(). Може виявитись, що скроллити по 600 пікселів за раз занадто “рвано” для вашого веб-застосунку, тож число треба знизити для більш плавної роботи. Або може виявитись, що 100мс є занадто малою затримкою (і так часто буває, особливо в браузерах, що емулють епплівські середовища), щоби відпрацюватискролл.

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

Іншими важливими параметрами toHaveScreenshot() є maxDiffPixels та maxDiffPixelRatio. Перший визначає максимально допустиму кількість розбіжних пікселів при порівнянні (наприклад, 100), другий — максимально допустиме співвідношення розбіжних пікселів до їх загальної кількості (наприклад, 0.01, тобто одному проценту пікселів дозволяється відрізнятися без провалу тесту). Ці параметри можна задати як під кожну конкретну перевірку, так і в конфігураційному файлі для всіх перевірок. Додавати їх слід обережно, розуміючи, навіщо і в якому саме значенні вони додаються. Зазвичай їх використання можна уникнути більш цільовими параметрами.

Одними з таких параметрів є mask та maskColor. Параметр mask приймає масив плейврайтівських локаторів — на скріншоті усі відповідні об’єкти сторінки буде замазано червоним прямокутником. Для чого це потрібно? Наприклад, для маскування елементів, які очевидним чином будуть змінюватися в часі — блоки новин, статей, будь-які лічильники, поточний час, дати тощо — а отже незаслужено фейлити тест. Параметр maskColor дозволяє задати колір маскування, якщо яскраво червоний вас не влаштовує.

Ще одними параметрами для конфігурації скріншотів є animations: disabled та caret: hide. Перший нівелює усі CSS- та веб-анімації. Якщо ці анімації є конечними, то перед скріншотом їх буде у пришвидшеному темпі програно до кінця. Зациклені анімації буде повернуто у початковий стан, їх програш відновиться після скріншоту. Параметр caret дозволяє приховати текстову каретку, якщо під час скріншоту відбувається робота із текстовими формами.