Playwright ці Cypress: хутчэйшы тэст можа патрабаваць больш CPU

Для новага E2E-набору Playwright варта праверыць першым, але хуткасць асобнага тэсту не вызначае кошт CI. У параўнанні пяці сцэнарыяў Angular ён выконваў тэсты хутчэй за Cypress, выкарыстоўваў менш аператыўнай памяці і крыху мацней нагружаў CPU. Гэты вынік датычыцца канкрэтнага прыкладання і ўмоў эксперыменту.

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

Што можна вынесці з лакальнага замеру

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

Большая сярэдняя загрузка CPU таксама не азначае аўтаматычна большы сумарны расход працэсарнага часу: карацейшы запуск можа змяніць вынік такога падліку. Аднак на выканаўцы, дзе працэсар ужо заняты збіраннем прыкладання ці іншымі задачамі, больш інтэнсіўная праца тэстаў можа стварыць канкурэнцыю за ядры. Лакальны замер не ўключае чаргу CI, чаканне вольнай машыны і час аб’яднання справаздач, таму яго нельга непасрэдна перанесці на вялікі размеркаваны набор.

Паралельнасць Playwright на адной машыне

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

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

Балансаванне Cypress Cloud паміж машынамі

Інструкцыя Cypress Cloud патрабуе рэжыму запісу для паралельнага запуску і апісвае размеркаванне цэлых spec-файлаў паміж даступнымі машынамі CI. Сэрвіс ацэньвае працягласць файлаў паводле гісторыі прагонаў і выдае наступны файл машыне, якая вызвалілася. Парадак выканання файлаў пры гэтым не гарантуецца.

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

Шарды Playwright у вялікім CI-наборы

Кіраўніцтва Playwright па шардах дазваляе запускаць часткі набору ў розных задачах CI. Звычайна падзел адбываецца на ўзроўні файлаў; пры ўключанай поўнай паралельнасці ён можа ісці на ўзроўні асобных тэстаў. У другім выпадку размеркаванне раўняе колькасць тэстаў паміж шардамі, але патрабуе, каб яны маглі працаваць незалежна.

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

Матрыца выбару паводле формы набору

• Малая лакальная серыя. Playwright — абгрунтаваны першы кандыдат для пілота: можна абмежаваць колькасць адначасовых працэсаў і паглядзець на час разам з CPU і памяццю. Для існага Cypress-набору спачатку ацаніце, ці ёсць наогул істотная затрымка, якую міграцыя павінна ліквідаваць.
• Вялікі набор з многіх spec-файлаў. Калі Cypress Cloud ужо наладжаны, параўноўвайце яго поўны прагон з шардамі Playwright на супастаўных машынах. Уключайце ў час чакання падрыхтоўку выканаўцаў, работу браўзераў і збор справаздач.
• Мала файлаў з доўгімі сцэнарыямі. Даданне машын можа амаль не дапамагчы, бо працу няма паміж чым размяркоўваць. Магчымасць падзяліць сцэнарыі залежыць ад таго, ці можна ізаляваць тэставыя даныя і прыбраць залежнасць ад парадку выканання.

Што павінен паказаць пілот перад міграцыяй

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

Збірайце асобна час сцэнарыя, час поўнага CI-задання, сумарны час працы машын, пікавую памяць і загрузку CPU. Фіксуйце няўдалыя запускі і паўторныя спробы: малы роскід працягласці не адказвае на пытанне, як часта тэсты падаюць без змены кода. Некалькі прагонаў дапамогуць аддзяліць устойлівую розніцу ад затрымкі падчас падрыхтоўкі асяроддзя.

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

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

• Апеляцыя Content ID хутчэйшая, але можа прынесці страйк
• Playwright ці Cypress: хуткасць тэстаў аплачваецца рознай складанасцю CI
• DigitalOcean Managed Agents: цыклічны агент можа спустошыць баланс