Playwright eller Cypress: fart og kostnad i CI

Playwright er et godt utgangspunkt når uavhengige ende-til-ende-tester skal kjøres parallelt i teamets egen CI. Cypress kan være et bedre valg når teamet arbeider mer effektivt med det, og Cypress Cloud blir særlig relevant når mange testfiler skal fordeles mellom maskiner. En raskere test gir likevel ikke nødvendigvis lavere samlet kostnad: Ventetid, maskinbruk og eventuell Cloud-bruk er forskjellige poster.

For en liten suite kan enkel skriving og feilsøking veie tyngre enn noen sekunders forskjell i kjøretid. For en stor suite blir det viktigere hvordan arbeidet fordeles, og hvor lenge den siste CI-jobben holder resten av kjøringen igjen. Tester som deler data, setter en ytterligere grense for hvor mye parallellitet som faktisk hjelper.

Hva hastighetsmålingen viser

I en publisert studie av en Angular 14-applikasjon ble fem testscenarioer kjørt uten synlig nettleservindu og gjentatt 50 ganger i hvert nettlesermiljø; applikasjonen brukte Spring Boot og MySQL. Playwright hadde kortere gjennomsnittlig kjøretid i alle scenarioene, og kjøretiden varierte mindre mellom gjentatte kjøringer. Forsøket foregikk lokalt, og testdata ble tilbakestilt mellom kjøringene.

Den mindre variasjonen gjelder kjøretid. Den sier ikke hvor ofte en test vil feile sporadisk i en bestemt CI-pipeline med nettverk, delte tjenester og andre belastninger. Studien målte heller ikke kostnaden ved å kjøre en stor suite på flere CI-maskiner. Resultatet er derfor et nyttig datapunkt for dette oppsettet, ikke en generell rangering av hva som blir raskest eller billigst i ethvert prosjekt.

Parallell kjøring på én maskin

Playwrights dokumentasjon om parallell kjøring beskriver hvordan testfiler kjøres samtidig som standard, i separate arbeiderprosesser med isolerte nettleserkontekster. Testene i samme fil kjøres normalt etter hverandre, mens antallet arbeidere kan begrenses i konfigurasjonen. Dermed kan teamet styre hvor mange prosesser en CI-jobb starter, uten å knytte denne lokale fordelingen til en egen skytjeneste.

Isolerte nettleserkontekster skiller blant annet informasjonskapsler og lagring mellom tester. De gir ikke hver test sin egen kopi av applikasjonens database eller eksterne tjenester. Hvis flere tester endrer samme bruker, ordre eller testkonto, kan flere arbeidere skape konflikter og omkjøringer. Den relevante grensen er altså ikke bare kapasiteten på CI-maskinen, men også hvor uavhengige testdataene er.

Fordeling mellom flere CI-maskiner

Når Playwright-suiten skal deles mellom CI-jobber, kan den deles i shards. Dokumentasjonen om sharding beskriver filbasert fordeling som standard; med fullyParallel kan individuelle tester fordeles mellom shards. Det siste gir finere inndeling når filene er ulikt store, men forutsetter at testene tåler å kjøre parallelt. Uten slik inndeling kan en tung fil gjøre at én jobb fortsetter lenge etter de andre.

Cypress Clouds dokumentasjon om parallellisering beskriver en løpende fordeling av hele spesifikasjonsfiler: CI-maskiner ber om arbeid, tjenesten anslår varigheten og tildeler en ny fil når en maskin blir ledig. Kjøringen må registreres i Cypress Cloud, og testene må ligge i flere filer for at det skal finnes arbeid å fordele. Rekkefølgen på filene er ikke garantert.

Forskjellen er viktig når filene tar ulik tid. Cypress Cloud kan gi ledige maskiner neste fil uten at teamet på forhånd bestemmer nøyaktig hvilke filer hver jobb skal kjøre. Tjenesten kan likevel ikke dele en spesifikasjonsfil som allerede kjører. Playwrights sharding gir teamet kontroll over inndelingen i egen CI-konfigurasjon; med filbasert fordeling må også der filenes størrelse passe noenlunde til antallet jobber.

Ventetid og regning er ulike mål

En CI-kjøring har minst to relevante tidsmål: tiden til siste jobb er ferdig, og summen av tiden alle maskinene er i bruk. Flere parallelle jobber kan senke det første målet uten å senke det andre. Som et rent regneeksempel: Hvis én jobb bruker ti minutter, mens fire samtidige jobber bruker fire minutter hver, faller ventetiden til fire minutter, men samlet bruk stiger fra ti til seksten maskinminutter. Oppstart, rapportering og eventuelle omkjøringer kan også påvirke regnestykket.

Cypress Clouds prisliste oppgir at gratisplanen Starter inkluderer parallellisering og 500 registrerte testresultater per måned. Et registrert resultat er en kjørt individuell test, ikke en hel suite; antallet vokser derfor både med størrelsen på suiten og med hvor ofte CI kjører den. Cloud-parallellisering krever ikke automatisk et betalt abonnement, men volumet kan gjøre en betalt plan relevant. CI-maskinene som utfører testene, må vurderes som en egen kostnad.

Den samme suiten bør vurderes med både tid til ferdig resultat og samlet maskinbruk i mente. En løsning som gir raskere tilbakemelding ved å starte flere jobber, kan være verdt kostnaden når utviklere ellers venter på CI. Hvis jobbene derimot ofte står ledige mens én lang testfil avsluttes, betaler teamet for kapasitet som knapt forkorter ventetiden. Det er fordelingen av den faktiske suiten, ikke farten til én test, som avgjør denne delen av valget.

Delt tilstand begrenser begge modellene

Verken lokale arbeidere eller fordeling mellom CI-maskiner gjør tester uavhengige hvis de endrer de samme dataene. En felles bruker, en database som nullstilles mens andre tester kjører, eller en begrenset ekstern testkonto kan gjøre utfallet avhengig av kjørerekkefølgen. Mer parallellitet kan da øke antallet konflikter selv om nettlesersesjonene er isolert.

Der det er mulig, gir egne data per test større rom for parallell kjøring. Tester som må bruke en delt ressurs, kan i stedet holdes sekvensielle, men denne delen av suiten vil fortsatt bestemme en nedre grense for total kjøretid. For slike miljøer er arbeid med testdata og avhengigheter ofte viktigere enn å legge til enda en CI-maskin eller øke antallet arbeidere.

Valget for små og store suiter

For en liten suite er Playwright et naturlig utgangspunkt når teamet ønsker parallell kjøring med direkte kontroll over arbeidere. Cypress kan være et like fornuftig valg dersom teamet allerede skriver, feilsøker og vedlikeholder testene effektivt der. En avgrenset hastighetsmåling alene gir svakt grunnlag for å flytte en fungerende suite.

For en stor CI-suite bør valget styres av hvor godt testene lar seg dele. Playwright passer når teamet vil styre inndelingen mellom egne jobber og kan holde testene uavhengige. Cypress Cloud er særlig interessant når mange spesifikasjonsfiler med ulik varighet kan tildeles løpende; da hører registrerte testresultater hjemme i kostnadsbildet sammen med maskinbruken. I begge tilfeller er den siste jobben og testenes delte tilstand det som til slutt setter grensen for gevinsten.

Les også: