Playwright ці Cypress: хуткасць тэстаў аплачваецца рознай складанасцю CI

Калі E2E-набор трэба запускаць у розных браўзерных рухавіках і каманда гатовая сама наладжваць падзел працы паміж CI-заданнямі, Playwright — моцны выбар. Калі важней перадаць балансаванне файлаў тэстаў Cypress Cloud і працаваць з замацаваным наборам браўзераў, варта разгледзець Cypress. Розніца ў хуткасці асобнага сцэнарыя яшчэ не вызначае працягласць усяго пайплайна.

Апублікаванае вымярэнне на Angular дае Playwright перавагу па часе выканання, але яго вынік адносіцца да канкрэтнай праграмы і лакальнага стэнда. Для CI вырашальныя таксама колькасць даступных машын, памер файлаў тэстаў і тое, ці запускаецца кожнае заданне ў аднолькавым асяроддзі.

Што вымералі на Angular

У даследаванні E2E-тэстаў Angular-праграмы Playwright завяршаў усе пяць сцэнарыяў хутчэй за Cypress; кожны сцэнар паўтаралі па 50 разоў у кожным браўзерным асяроддзі. Аўтары запускалі праверкі без графічнага інтэрфейсу на адным лакальным камп’ютары. Праграма прызначалася для трэніроўкі чытання, набору тэксту і памяці; сцэнарыі ахоплівалі рэгістрацыю, практыкаванні і працу са зваротамі карыстальнікаў.

У гэтым эксперыменце час запуску Playwright таксама менш вагаўся паміж паўторамі. Пры гэтым яго тэсты крыху больш нагружалі працэсар, затое патрабавалі менш аператыўнай памяці. Такія вынікі дапамагаюць ацаніць абмен паміж часам і рэсурсамі менавіта для даследаванай нагрузкі. Размеркаванне часу не вымярала долю выпадковых збояў у працоўным праекце: для гэтага патрэбныя іншыя даныя аб няўдалых прагонах і іх прычынах.

Лакальны запуск не ўключаў чаргу CI, падрыхтоўку некалькіх агентаў і збор вынікаў з розных заданняў. Таму перавага ў часе сцэнарыяў можа змяніць агульную працягласць пайплайна па-рознаму. Напрыклад, калі самыя доўгія тэсты застаюцца ў адным заданні, дадатковыя машыны не скароцяць чаканне прапарцыйна іх колькасці. Гэта выснова пра механіку паралельнай працы, а не асобны вынік Angular-эксперыменту.

Браўзеры і межы іх падтрымкі

Дакументацыя Playwright аб браўзерах апісвае запуск у Chromium, Firefox і WebKit, а таксама ў брэндаваных Google Chrome і Microsoft Edge. Браўзеры можна аформіць як асобныя праекты адной канфігурацыі. Пры гэтым зборка WebKit у Playwright не з’яўляецца самой праграмай Safari, а яго Firefox адрозніваецца ад брэндаванай версіі: калі патрабаванне называе канкрэтны выпуск браўзера, назвы рухавіка недастаткова.

У Cypress таксама даступныя браўзеры сямейства Chrome, Firefox і эксперыментальная падтрымка WebKit. Для WebKit трэба асобна ўключыць адпаведную опцыю і ўсталяваць пакет playwright-webkit; у гэтым рэжыме ёсць пералічаныя ў дакументацыі абмежаванні. Таму розніца паміж інструментамі заключаецца не ў простай наяўнасці ці адсутнасці WebKit, а ў статусе падтрымкі і падрыхтоўцы асяроддзя. Для Chrome, Edge і Firefox таксама трэба вызначыць патрэбную версію і пераканацца, што яна даступная на CI-агенце.

Шырэйшая матрыца азначае больш запускaў аднаго і таго ж набору. Калі дадатковы браўзер абавязковы толькі для часткі функцый, асобная група такіх праверак можа быць разумнейшай за поўнае дубляванне ўсіх сцэнарыяў. Гэта ўжо выбар ахопу тэставання: сам фрэймворк не вызначае, колькі браўзераў патрабуе прадукт.

Асяроддзе CI і паралельнае выкананне

Інструкцыя Cypress па пераходзе апісвае афіцыйныя Docker-вобразы з тэгамі для канкрэтных версій Node.js і браўзераў, а таксама паралельны запуск праз Cypress Cloud. Вобраз cypress/browsers пакідае версію самога Cypress залежнасцю праекта; cypress/included можа ўключаць і яе. Калі замацаваць патрэбны тэг, абнаўленне стандартнага асяроддзя CI-правайдара не падменіць браўзер у тэсце незаўважна. Адпаведнасць вобраза і залежнасцяў праекта ўсё роўна трэба падтрымліваць пры планавых абнаўленнях.

Playwright таксама мае гатовы Docker-вобраз і каманду для ўстаноўкі браўзераў. Версія пакета звязаная з пэўнымі браўзернымі зборкамі, таму пасля абнаўлення пакета можа спатрэбіцца паўторная ўстаноўка. Для паўтаральнасці на розных агентах важны не сам факт выкарыстання Docker, а ўзгодненая версія пакета, браўзераў і сістэмных залежнасцяў. Інакш аднолькавы тэст можа атрымаць розныя ўмовы яшчэ да пачатку выканання.

Рэкамендацыі Playwright для CI прапануюць адзін worker на звычайным агенце дзеля стабільнасці, а для шырэйшай паралельнасці — шарды ў асобных заданнях. Гэта пакідае камандзе кантроль над колькасцю заданняў і рэсурсамі кожнага з іх, але патрабуе наладзіць падзел набору і збор вынікаў. Павелічэнне колькасці worker-працэсаў на слабым агенце можа даць канкурэнцыю за працэсар і памяць замест выйгрышу ў часе.

Cypress Cloud размяркоўвае паміж машынамі файлы спецыфікацый з улікам ранейшай працягласці іх выканання. Для гэтага запуск трэба запісваць у Cloud, а CI-машынам патрэбная сувязь з сэрвісам. Адзін вялікі файл застаецца адной адзінкай працы: нават калі суседнія машыны ўжо вызваліліся, яны не забяруць з яго частку праверак. Такі спосаб здымае з каманды ручное балансаванне файлаў, але робіць іх памер і структуру істотнымі для выніку.

Які выбар адпавядае праекту

• Шырокая браўзерная матрыца. Playwright зручны, калі патрэбныя некалькі рухавікоў у адной канфігурацыі. Спачатку варта адрозніць патрабаванне да рухавіка ад патрабавання да канкрэтнага брэндаванага браўзера.
• Angular-праграма, дзе чакаюць вынік доўгіх E2E-праверак. Апублікаваны лакальны эксперымент дае падставу разглядаць Playwright у першую чаргу. Працягласць уласнага CI-запуску ўсё ж залежыць ад яго сцэнарыяў і размеркавання працы.
• Шмат асобных файлаў тэстаў і некалькі CI-машын. Cypress Cloud можа быць зручным, калі каманда прымае запіс запускаў у сэрвісе. Для набору з некалькіх вельмі вялікіх файлаў аўтаматычнае балансаванне мае менш магчымасцяў.
• Частыя змены асяроддзя агентаў. Замацаваны Docker-вобраз Cypress дапамагае кантраляваць версіі Node.js і браўзераў. У Playwright тая ж мэта патрабуе ўзгадняць версію пакета з яго браўзернымі зборкамі.

Калі рашэнне ўплывае на існы набор тэстаў, карысна параўнаць адзін карыстальніцкі шлях у патрэбных браўзерах, а затым поўны запуск з рэальнай колькасцю CI-заданняў. Першае пакажа час выканання сцэнарыя, другое — колькі каманда чакае выніку і дзе ўзнікае кошт падтрымкі пайплайна.

Чытайце таксама:

• Docker ці Podman: rootless не вызначае пераможцу па хуткасці
• OBS ці StreamYard: бясплатны эфір аплачваецца гадзінамі налады