Playwright eller Cypress? Parallelle CI-tests vender det oplagte valg

Playwright er det stærkeste udgangspunkt, når mange uafhængige E2E-tests skal køre parallelt, eller når WebKit er et fast browserkrav. Playwrights paralleliseringsmodel kører som standard testfiler i separate worker-processer med isolerede BrowserContext-miljøer. Teamet kan begrænse antallet af workers efter den CPU og hukommelse, som CI-maskinen faktisk har.

Cypress kan være et fornuftigt valg for en mindre suite, som allerede fungerer godt. Skal flere CI-maskiner forkorte ventetiden, bliver arkitekturen afgørende: Cypress Clouds parallelisering kræver en optaget kørsel og fordeler hele spec-filer mellem maskinerne. Den mulige gevinst i svartid skal derfor holdes op mod både maskinforbrug og eventuelle Cloud-udgifter.

Browserkravet kan afgøre valget tidligt

Begge værktøjer kan teste i Chrome-familien og Firefox. Playwrights browseroversigt omfatter desuden WebKit som et almindeligt testprojekt ved siden af Chromium og Firefox. Playwrights WebKit er en særskilt browserbygning og ikke den mærkevareudgave af Safari, der åbnes på en Mac. Hvis blandt andet medieafspilning er vigtig, kan operativsystemet også påvirke, hvor tæt testen kommer på brugerens Safari-oplevelse.

Cypress’ browseroversigt angiver Chrome-familien, Edge og Firefox som understøttede browsere, mens WebKit fortsat er eksperimentel og kræver særskilt aktivering. Et team, der vil gøre WebKit til et fast krav i hver CI-kørsel, får derfor en mere ligetil driftsmodel med Playwright. Hvis browserkravet kun omfatter Chrome og Firefox, er browserdækningen alene ikke en grund til at migrere en velfungerende suite.

Isolation og filstruktur bestemmer, hvor meget der kan køre samtidig

Playwrights BrowserContext holder cookies og lokal browserlagring adskilt mellem tests. Isolationen omfatter ikke automatisk applikationens database: To samtidige tests, der ændrer den samme bruger eller ordre, kan stadig påvirke hinandens resultat. Separate testkonti eller entydige data er derfor nødvendige, før flere workers giver en stabil gevinst.

Som standard kører Playwright testfiler parallelt, mens tests i samme fil køres i rækkefølge; parallel kørsel inden for en fil kan slås til. Cypress Clouds fordelingsenhed er en hel spec-fil. En meget lang spec kan derfor blive tilbage på én maskine, efter at de andre er færdige. Flere nogenlunde afbalancerede specs giver Cloud mere arbejde at fordele, men en opdeling må ikke bryde de dataafhængigheder, som testene faktisk har.

Den forskel gør filstrukturen til en del af CI-arkitekturen. En suite med få, store specs får ikke nødvendigvis fuldt udbytte af flere Cypress-maskiner. En Playwright-suite med mange filer kan omvendt blive presset af for mange samtidige browsere på én lille maskine. Antallet af workers, spec-fordelingen og adskillelsen af testdata bør derfor vurderes sammen.

Den offentliggjorte måling har en klar grænse

Angular-undersøgelsen i Journal of Computer Sciences Institute fra 2025 målte kortere køretider og lavere RAM-forbrug med Playwright i de undersøgte lokale testforløb. I det første scenarie var det gennemsnitlige RAM-forbrug cirka 214 MB for Playwright og 604 MB for Cypress. Forskerne fandt også mindre variation i køretiden for Playwright og lidt højere CPU-belastning.

Undersøgelsen brugte én Angular-applikation på én lokal Windows-computer, ikke komplette CI-pipelines med ens maskinbudget. Forskerne sammenlignede også testkodens længde: Playwright brugte færre kodelinjer i de fleste scenarier, men ikke i det sidste. Kortere kode kan gøre en test lettere at overskue; forsøget målte ikke fremtidig vedligeholdelsestid. RAM-tallene er derfor et konkret tegn på, hvad der skete i dette setup, ikke en fast kapacitetsregel for enhver suite.

Flere maskiner ændrer både svartid og pris

En CI-kørsel har to forskellige tidsmål: Hvor længe udvikleren venter på resultatet, og hvor meget samlet maskintid alle jobs bruger. Parallelle jobs kan sænke det første mål, selv om opstart, installation og samtidig kørsel øger det andet. Også gentagne kørsler efter fejl tæller med i regnestykket. En lokal hastighedsmåling kan ikke afgøre, hvad teamet betaler hos sin CI-udbyder.

Playwright kan dele suiten mellem CI-jobs med shards og behøver ikke Cypress Cloud til den fordeling. Uden særskilt parallel indstilling sker sharding på filniveau; med fuld parallelisering kan de enkelte tests fordeles mere fint. Begge valg bruger stadig CI-kapacitet. Cypress Cloud tildeler derimod ledige maskiner nye hele spec-filer under kørslen. Den dynamiske fordeling kan være nyttig, når filernes varighed varierer, men den kan ikke dele en enkelt langsom spec op midt i kørslen.

En sammenligning af pris bør derfor bruge samme testmængde og browsermatrix og tælle både tid til resultat og summen af maskinernes køretid. Medregn den konkrete CI-takst og Cloud-aftalens vilkår, hvis Cloud indgår. Først da er det muligt at skelne mellem en hurtigere pipeline og en billigere pipeline.

Tre projektscenarier gør forskellen konkret

Disse scenarier er beslutningsrammer, ikke benchmarkresultater. For at sammenligne værktøjerne meningsfuldt må applikation, testdata, browserbygninger og CI-maskintype holdes så ens som muligt. Registrér også RAM-forbrug og fejl ved gentagne kørsler; en større maskine eller en ændret browsermatrix må ikke forveksles med en gevinst fra testværktøjet.

1. Lille suite på én CI-maskine: Hvis Cypress allerede afslutter stabile tests inden for teamets acceptable ventetid, er parallelisering alene en svag begrundelse for migration. Playwright bliver interessant, hvis maskinen har plads til flere workers, og testene kan køre uden fælles data, der skaber konflikter. Sammenlign på den browser, produktet faktisk kræver.
2. Flere browsere som fast udgivelseskrav: Kør de samme forløb i hver krævet browser, og opgør varighed og fejl pr. browser. Når WebKit skal indgå på lige fod med Chromium og Firefox, er Playwright det mere oplagte udgangspunkt. Den valgte WebKit-kørsel skal stadig passe til de Safari-forhold, som betyder noget for produktets brugere.
3. Stor suite fordelt på flere CI-jobs: Sammenlign Playwrights workers og shards med Cypress Clouds fordeling af hele specs. Her kan ventetid, filernes forskellige varighed og summen af faktureret maskintid pege i hver sin retning. Hvis teamet selv fordeler Cypress-specs mellem jobs uden Cloud-orkestrering, skal arbejdet med at holde fordelingen i balance også indgå i valget.

Læs også:

• Fourthwall eller Shopify? Den gratis butik giver et smallere maskinrum
• Hviske eller Whisper til dansk tale? Lokalt valg koster funktioner
• Pleo eller Spendesk? Flere medarbejdere kan vende prismodellen