Playwright vai Cypress? Rinnakkaisajon infratarve

Playwright on vahva lähtökohta tiimille, joka tarvitsee useita selainprojekteja ja haluaa ajaa testejä rinnakkain omalla CI-koneellaan. Cypress sopii tiimille, joka arvostaa sen paikallista vianjäljitystä; Cypress Cloud voi jakaa testit useille CI-koneille, kun ajot tallennetaan palveluun. Valinnassa ratkaisee myös se, kuinka paljon konekapasiteettia ja työnjaon hallintaa tiimi haluaa järjestää itse.

Rinnakkaisajolla tarkoitetaan tässä kahta eri asiaa: samalla koneella toimivia testiprosesseja ja testisarjan jakamista erillisiin CI-töihin. Nopeusmittaus ei korvaa tätä erottelua, sillä tulokseen vaikuttavat myös käytetty kapasiteetti, testien rakenne ja selainmatriisi. Siksi selaimet kannattaa rajata ennen kuin vertailee arvioituja ajoaikoja tai pilvipalvelun hyötyä.

Selaintuki voi ratkaista valinnan ensin

Playwrightin ajo-ohje näyttää, että määritettyjä selainprojekteja voi ajaa samalla komennolla ja että testit suoritetaan oletuksena rinnakkain. Ohjeessa WebKit- ja Firefox-projektit voidaan valita myös yhdessä. Jos hyväksymiskriteerit koskevat eri selainmoottoreita, projektit tekevät niiden tuloksista erikseen tarkasteltavia ilman, että joka selaimelle tarvitaan omaa testikoodia.

Cypressin selaintukikuvaus kattaa Chrome-perheen selaimet, Edgen ja Firefoxin, mutta merkitsee WebKit-tuen kokeelliseksi. WebKitin käyttö edellyttää erillistä asetusta ja WebKit-paketin asennusta. Jos WebKit on julkaisun pakollinen hyväksymisehto, kokeellinen tuki on olennainen ero; jos tiimin matriisi koostuu Chromesta, Edgestä ja Firefoxista, pelkkä selainten luettelo ei tee päätöstä sen puolesta. Selainmoottorin testiä ei myöskään pidä automaattisesti tulkita samanlaiseksi vaatimukseksi kuin testiä varsinaisessa Safari-selaimessa.

Yhden koneen rinnakkaisuus ei tarkoita rajatonta kapasiteettia

Playwright jakaa testitiedostoja worker-prosesseille samalla koneella. Oletus antaa mahdollisuuden hyödyntää koneen suorittimia ilman erillistä pilvipalvelua, mutta useampi worker kuluttaa myös muistia ja käynnistää selaimia. Kun CI-kone on pieni tai testattava sovellus tarvitsee paljon resursseja, worker-määrän kasvattaminen voi jopa heikentää ajon vakautta. Siksi yhden koneen suorituskykyä on mielekästä arvioida sen todellisella kapasiteetilla.

Testitiedostojen rakenne määrää, kuinka tasaisesti työ jakautuu. Pitkässä tiedostossa peräkkäin ajettavat testit voivat pitää yhden workerin kiireisenä sen jälkeen, kun muut ovat jo valmistuneet. Sama käyttäjätili tai muu muuttuva testidata voi puolestaan aiheuttaa ristiriitoja samanaikaisille testeille. Nämä ovat testisarjan ominaisuuksia: uusi ajotyökalu ei yksin poista jaetusta tilasta johtuvaa epävarmuutta.

Usean CI-koneen työnjako tehdään eri tavoin

Playwrightin sharding-ohjeessa testisarja jaetaan --shard-valinnalla erillisiin CI-töihin. Ilman fullyParallel-asetusta jako tehdään testitiedostojen tasolla; asetuksen kanssa yksittäisiä testejä voidaan jakaa eri osiin. CI-järjestelmän on silti käynnistettävä työt ja tuotava niiden raportit yhteen. Jos tiedostojen kestot vaihtelevat paljon, tiedostotasoinen jako voi jättää yhden työn käyntiin muiden valmistuttua.

Cypress Cloudin rinnakkaistusohje kuvaa toisenlaisen työnjaon: palvelu arvioi spec-tiedostojen kestot ja antaa kokonaisia tiedostoja vapaana oleville CI-koneille yksi kerrallaan. Toiminto vaatii tallennetun ajon sekä --record- ja --parallel-valinnat. CI-koneet täytyy silti varata ja käynnistää erikseen. Pilvipalvelu hoitaa dynaamisen jaon käytettävissä olevien koneiden välillä, mutta yksi pitkä spec-tiedosto pysyy tämän mekanismin kannalta yhtenä työnä.

Cypress-testit voi jakaa myös itse erillisiin CI-ajoihin. Se on eri ratkaisu kuin Cloudin automaattinen kuormantasaus: tiimi määrittää silloin, mitkä tiedostot kuuluvat mihinkin työhön, ja ylläpitää jakoa testisarjan muuttuessa. Playwrightin shardingissa puolestaan osien määrä määritetään etukäteen. Kummassakin mallissa lisäkoneista on hyötyä vasta, kun testit ja niiden tarvitsema ympäristö sallivat samanaikaisen ajon.

Mistä CI-kustannus syntyy?

Vertailtava kustannus ei ole pelkkä yksittäisen ajon kellonaika. Samalle testisarjalle on huomioitava CI-koneiden käyttöaika, samanaikaisesti varattu kapasiteetti, raporttien kokoaminen ja mahdollinen Cypress Cloudin käyttö. Lyhyempi odotusaika voi vaatia useampia yhtä aikaa käyviä koneita, vaikka koneiden yhteenlaskettu käyttöaika ei vähenisi samassa suhteessa. Tämä erottaa julkaisujonon nopeuden varsinaisesta infrakustannuksesta.

Playwrightin paikallinen rinnakkaisuus voi riittää yhdellä koneella ilman usean työn koordinointia. Kun sarja kasvaa, sharding lisää CI-töiden määrää ja raportoinnin järjestelyä. Cypress Cloud voi vähentää tiedostojen jakamiseen liittyvää omaa ylläpitoa, mutta palvelun tarve tulee mukaan päätökseen. Kummankaan mallin kokonaiskustannusta ei voi päätellä työkalun ominaisuusluettelosta ilman tietoa tiimin ajojen määrästä ja käytettävistä koneista.

Virheen jäljittämisessä paikallinen ajo ja CI-jälki palvelevat eri hetkiä

Playwrightin käyttöliittymätilassa testin vaiheita voi käydä läpi, ja HTML-raportista epäonnistumisia voi suodattaa selaimen sekä tuloksen mukaan. Tämä auttaa paikantamaan, koskeeko vika tiettyä selainprojektia vai koko testisarjaa. CI:ssä syntyneestä virheestä on hyötyä vain, jos tarvittava jälki tai raportti säilytetään ajon jälkeen.

Cypressin avoimessa paikallisessa ajossa komentoloki näyttää suoritetut komennot ja niihin liittyvät näkymän tilat. Kehittäjä voi tutkia sovellusta näkyvässä selaimessa ja pysäyttää testin virheen kohdalle. Kun vika esiintyy vain CI:ssä, paikallinen toisto ei kuitenkaan yksin kerro alkuperäisen ajon tapahtumia. Tiimin kannattaa siis verrata käytännössä, saako se talteen tarvitsemansa virhetiedot siitä ajotavasta, jota se eniten käyttää.

Julkaistu nopeusmittaus kuvaa yhtä asetelmaa

PlaywrightLabin 5. tammikuuta 2025 julkaisemassa mittauksessa käsiteltiin 1 000 testitapausta kolmessa sovelluksessa: Playwrightin ajaksi ilmoitettiin 12 minuuttia kahdeksalla rinnakkaisella workerilla ja Cypressin ajaksi 45 minuuttia neljällä. Ilmoitetut ajat ovat kyseisen asetelman tuloksia. Eri worker-määrien vuoksi niistä ei voi erottaa, kuinka suuri osuus aikaerosta johtui itse työkalusta.

Julkaisu ei erittele riittävästi esimerkiksi koneiden kapasiteettia, toistokertoja tai testien vastaavuutta, jotta luvut voisi siirtää suoraan toisen tiimin CI-putkeen. Se myös esittää tuloksen PlaywrightLabin omana vertailuna, joten sitä kannattaa käsitellä yksittäisenä mittauksena eikä yleisenä nopeuslupauksena. Hankintaa varten olennaisempaa on, miten sama edustava testijoukko käyttäytyy tiimin vaatimilla selaimilla ja sillä konekapasiteetilla, jonka tiimi voi todella varata.

Valinta selainmatriisin ja työnjaon perusteella

Jos WebKit on pakollinen ja tiimi haluaa aloittaa rinnakkaisajon omalla CI-koneella, Playwrightin selainprojektit ja oletusrinnakkaisuus tekevät siitä perustellun ensivalinnan. Jos selainmatriisi sopii Cypressin tukeen, sen paikallinen komentoloki on tiimille hyödyllinen ja useiden CI-koneiden spec-tiedostot halutaan jakaa dynaamisesti, Cypress Cloudilla on selvä rooli. Pilvipalvelun käyttö on silloin osa infrastruktuuripäätöstä.

Ratkaiseva raja kulkee usein testisarjan koossa ja rakenteessa. Yksi kone voi riittää lyhyelle, hyvin jakautuvalle sarjalle; pitkä sarja voi hyötyä useasta CI-työstä vain, jos sen testit ovat riippumattomia ja työ voidaan jakaa tasaisesti. Valinnassa kannattaa painottaa sitä työnjakoa, jonka tiimi pystyy ylläpitämään, sekä virhetietoja, joita sen julkaisuputki tarvitsee.

Lue myös: