Slik setter du opp Playwright i eksisterende prosjekter uten å ødelegge noe

End-to-end testing føles ofte som noe man «en gang skal få på plass», men som aldri passer inn i kalenderen. Samtidig vokser risikoen for at en liten endring knuser noe kritisk i produksjon uten at noen merker det før kundene gjør det.

Playwright er et moderne verktøy som kan hjelpe, men terskelen føles ofte høy når koden din allerede er i full drift. Denne guiden viser en trygg, trinnvis måte å få Playwright inn i et eksisterende prosjekt uten å velte alt du har fra før.

Hva er Playwright og når passer det inn?

Playwright er et testverktøy for nettapplikasjoner som lar deg automatisere ekte nettlesere som Chromium, Firefox og WebKit. Du kan skrive tester i blant annet TypeScript, JavaScript, Python, Java og .NET, og kjøre dem mot både lokal og deployet kode.

Typiske situasjoner der Playwright gir mening er når du har kritiske brukerreiser som alltid må fungere, når du har mange regresjoner mellom releaser eller når teamet bruker mye tid på manuell klikk-testing i ulike nettlesere.

Planlegg innføringen før du installerer noe

Før du slipper enda et verktøy inn i repoet er det lurt å avklare hvor Playwright skal inn i bildet. Bestem først hvilket språk og testrammeverk dere vil bruke, for eksempel TypeScript med den innebygde test runneren i Playwright om prosjektet allerede har Node-baserte verktøy.

Sett deretter et tydelig mål for første runde: for eksempel å dekke én kritisk brukerflyt fra innlogging til checkout. Med én konkret flyt blir det enklere å holde første oppsett lite, reverserbart og lærerikt.

Installasjon i et eksisterende Node-bibliotek eller frontprosjekt

I et prosjekt som allerede bruker Node og en pakkebehandler som npm eller pnpm, kan du installere Playwright lokalt som utviklingsavhengighet. Vanlig fremgangsmåte er å kjøre Playwrights egen init-kommando som legger til testkonfigurasjon og eksempeltester.

Etter installasjonen bør du gå gjennom hva som ble lagt til: konfigurasjonsfil, test-mapper, scripts i package.json og eventuelle Git-ignoreregler. Rydd vekk ting dere ikke vil bruke, og tilpass mappestruktur slik at den passer resten av prosjektet.

Isoler testmiljøet så godt som mulig

Når Playwright kommer inn i et eksisterende prosjekt er det lett å blande test- og applikasjonskode. Lag derfor en egen toppmappe, for eksempeltests/e2e, og hold alt relatert til Playwright der: konfigurasjon, fixtures, helpers og selve testene.

Hvis projektet har flere apper eller domener kan det også være nyttig å lage undermapper for ulike områder. Målet er at nye utviklere raskt forstår hvor end-to-end-testene bor, uten å måtte lese hele repo-historikken.

Koble Playwright mot en stabil URL

Ett av de vanligste problemene er at tester peker mot feil miljø. Bestem på forhånd om første runde skal kjøre mot lokalt miljø, et dedikert testmiljø eller staging. For mange er et fast testmiljø enklest, siden data og integrasjoner ofte er mer like produksjon.

Legg URLer i konfigurasjon i stedet for å hardkode dem i testene. For eksempel kan du bruke miljøvariabler som leses inn av Playwright-konfigen, slik at du enkelt kan bytte mellom lokal og ekstern adresse i ulike pipelines.

Start med én robust «happy path»

Det er fristende å teste alt med en gang, men for å bygge tillit til verktøyet er det bedre å starte med én robust test. Velg en brukerflyt som er forretningskritisk og relativt stabil, for eksempel registrering, pålogging eller en sentral bestillingsprosess.

Skriv testen så eksplisitt som mulig: naviger til siden, fyll inn felter, klikk på knapper og verifiser tekst og URLer. Unngå for mye «magisk» logikk i helper-funksjoner i starten, så det er lett å se hva som skjer når en test feiler.

Håndter flakiness fra start

En vanlig grunn til at end-to-end-tester blir skrudd av igjen er at de feiler tilfeldig. Playwright har innebygget ventelogikk som hjelper, men du må fortsatt være bevisst på hva du venter på. I stedet for faste tidsforsinkelser er det bedre å vente på konkrete elementer eller tilstander.

Hvis applikasjonen din er tung på asynkrone kall eller websockets, kan det lønne seg å lage egne små hjelpere for å vente på ferdig lasting. Målet er at tester enten feiler av en reell grunn, eller kjører grønt, ikke noe midt imellom.

Integrer i CI uten å lamme pipeline

Når du er fornøyd lokalt er neste steg å koble Playwright på CI. For mange team er det lurt å starte med en egen, valgfri job i pipeline, slik at du kan følge med på stabilitet og kjøretid uten å blokkere alle merges fra dag én.

Etter hvert som testene modnes kan du stramme inn: krav om grønne end-to-end-tester for bestemte branches, for eksempel release- og main-brancher. Sørg også for at artifacts som HTML-rapporter og eventuelle feilscreenshots lagres, slik at feilsøking går raskere.

Vanlige feil å unngå i eksisterende prosjekter

En klassisk tabbe er å prøve å speile hele domenemodellen i testene, med masse intern forretningslogikk. Hold i stedet testene nær brukeropplevelsen, og gjenbruk kun det som gir bedre lesbarhet, som selector-helpers eller innloggingsrutiner.

En annen felle er å introdusere Playwright i en isolert gren som aldri merges, fordi det «skal bli perfekt først». Legg heller opp til små, hyppige commits, og aksepter at første versjon er enkel så lenge den kjører stabilt og gir verdi.

Bygg gradvis dekning over tid

Når første runde fungerer er det fristende å dekke hele applikasjonen med Playwright. Ofte er det mer fornuftig å bruke end-to-end til de viktigste flytene, og la resten dekkes av integrasjons- og enhetstester.

Lag en enkel prioriteringsliste over kritiske scenarier, og legg til nye Playwright-tester når dere først jobber i det området av koden. På den måten følger testene den naturlige utviklingsrytmen, i stedet for å bli et sideprosjekt som aldri blir ferdig.

Oppsummering: liten start, tydelig gevinst

Nøkkelen til å få Playwright inn i et etablert prosjekt er å starte lite, holde alt godt isolert og knytte testene til konkrete, viktige brukerreiser. Da unngår du å rive opp eksisterende struktur, samtidig som du raskt får bedre trygghet rundt hver release.

Etter hvert som teamet ser at testene gir reell verdi og ikke bare ekstra støy, er det mye enklere å investere mer tid i bedre dekning, ytelse og integrasjon i pipeline.