Slik får du Cypress til å spille på lag med prosjektet ditt

Cypress har blitt et populært verktøy for ende-til-ende-testing av webapplikasjoner, men mange gir opp etter første friksjon. Det er synd, for brukt riktig kan Cypress fange feil før de når produksjon og gjøre endringer tryggere.

I denne artikkelen ser vi på hvordan du faktisk får Cypress inn i en eksisterende kodebase uten at alt stopper opp. Fokus ligger på konfigurasjon, struktur og enkle mønstre som gjør testene mer robuste og mindre skjøre.

Hva Cypress er bra til, og når det passer dårlig

Cypress fungerer spesielt godt til å teste brukerflyt i moderne webapper der mye logikk ligger i frontend. Det gir rask tilbakemelding lokalt, og du ser nøyaktig hva som skjer i nettleseren.

Samtidig er Cypress ikke alltid riktig verktøy. Skal du teste svært tunge backend-prosesser, komplekse integrasjoner eller gammel teknologi som ikke fungerer godt i moderne nettlesere, kan det være lurt å kombinere Cypress med andre testtyper.

Første steg: legg Cypress inn i dagens verktøykjede

Start med å installere Cypress som en utviklingsavhengighet i prosjektet ditt, ikke globalt. Da er det tydelig hvilken versjon som hører til prosjektet, og det blir enklere å gjenskape feil i teamet.

Lag deretter et eget npm- eller pnpm-script for å kjøre Cypress, for eksempel ett for GUI og ett for headless. Det gjør terskelen lavere for å ta det i bruk, og gjør det enklere å koble på kontinuerlig integrasjon senere.

Struktur på tester: hold deg nær funksjonaliteten

En vanlig felle er å lage en stor mappe med «tester for alt». Det blir raskt uoversiktlig, og testene mister koblingen til funksjonaliteten de verifiserer. Plasser i stedet testene logisk etter funksjonelle områder eller sider.

For eksempel kan du ha en mappe for innlogging, en for handlekurv og en for administrasjon. I hver mappe legger du både testfiler og eventuelle hjelpere som kun angår dette området, i stedet for å samle alt i en global utils-fil.

Stabile selektorer: slutt å teste på CSS-klasser

En av årsakene til at ende-til-ende-tester får dårlig rykte, er at de ofte brekker på hver minste UI-endring. Mye skyldes valg av selektorer. CSS-klasser og tekstinnhold endres ofte, mens enkle data-attributter er mer stabile.

Avtal i teamet at interaktive elementer som skal brukes i tester får egne data-attributter, for eksempeldata-cyellerdata-testid. Da kan du skrive tester som er robuste selv om du justerer layout, navn eller struktur.

Håndtering av nettverkskall uten flaky tester

Uten kontroll på nettverkskall blir Cypress-tester gjerne trege eller ustabile. Tidligere var det vanlig å legge inn vilkårlige «vent i X sekunder», men det gir skjøre tester og skjuler reelle problemer.

Bruk i stedet Cypress sin innebygde støtte for å observere og eventuelt mocke nettverkskall. Angi hvilken URL eller rute du forventer, vent eksplisitt på svaret, og verifiser deretter resultatet i UI. På den måten måler du faktisk at applikasjonen har gjort det den skal, ikke bare at tiden har gått.

Test bare det som betyr noe: unngå overlapp og duplikater

Det er fristende å dekke absolutt alt med ende-til-ende-testing, men det gir ofte langvarige og sårbare testløp. Tenk i stedet på Cypress som verktøyet du bruker til å verifisere de viktigste brukerreisene og integrasjonene.

La enhets- og integrasjonstester ta seg av detaljer og spesifikke kanttilfeller. Cypress kan så fokusere på at hovedflytene fungerer på tvers av lagene: innlogging, betaling, registrering, endring av viktige data og lignende.

Bygg en enkel «happy path» først, så utvid

Mange prosjekter skyter seg i foten ved å starte med kompliserte scenarier som inneholder mye forretningslogikk og flere integrasjoner. Begynn i stedet med én enkel, men forretningskritisk flyt, for eksempel ny bruker registrerer seg og får bekreftelse.

Når du har én stabil test som går grønt hver gang lokalt og i CI, kan du utvide med flere scenarioer. Bruk gjerne samme mønster: oppsett av data, handlinger i UI, verifisering av resultat og opprydding når det trengs.

Integrasjon i CI: rask tilbakemelding uten å stoppe alt

Når Cypress først er oppe og går lokalt, er det fristende å slenge alle testene inn i hovedløypa i CI. Det kan fort gjøre hver pull request unødvendig treg, spesielt hvis du også bygger, kjører enhetstester og kjører analyser.

Et alternativ er å starte med et lite sett prioriterte Cypress-tester som kjøres på hver endring til hovedbranch, mens resten kjører sjeldnere, for eksempel om natten. Etter hvert som testpakken modnes, kan du justere hva som skal kjøres når.

Typiske feilkilder og hvordan du unngår dem

En del problemer går igjen når Cypress tas i bruk. Et klassisk eksempel er at testene forventer en helt ren og forutsigbar database, mens utviklingsmiljøet ditt er fullt av gamle data. Da kan samme test gi forskjellige resultater fra gang til gang.

Prøv i stedet å sette opp en egen database for Cypress, eller rutiner for å opprette og rydde opp i testdata per kjøring. Hvis det ikke er mulig, sørg i det minste for at testene alltid oppretter sine egne data og ikke er avhengige av forhåndstilstand.

Lag testkode som en del av kodebasen, ikke som et vedlegg

Cypress gir mest verdi når testene behandles som fullverdige borgere i repoet. Det betyr at de får kodegjennomgang, samme kvalitetssikring som annen kode og refaktorering når applikasjonen endres.

Sørg for at nye funksjoner som påvirker brukerflyt, normalt får med minst én Cypress-test før de merges. Over tid får du da et nett av tester som speiler de viktigste interaksjonene i produktet, og som faktisk vedlikeholdes.