Slik setter du opp Playwright lokalt for stabile ende-til-ende-tester i webprosjekter

Ende-til-ende-tester har rykte på seg for å være trege, skjøre og vanskelige å drifte. Playwright forsøker å løse nettopp dette, men mange gir opp før verktøyet er skikkelig på plass lokalt.

I denne artikkelen går vi gjennom hvordan du kan sette opp Playwright lokalt på en måte som gjør at testene blir forutsigbare, forholdsvis raske og en naturlig del av arbeidsflyten din, ikke et ekstra irritasjonsmoment.

Hva er Playwright, og når er det verdt å ta i bruk

Playwright er et testverktøy som lar deg styre ekte nettlesere programmert, for å teste webapplikasjonen fra utsiden slik en menneskelig besøker ville gjort. Du kan klikke, fylle inn felter, sjekke tekst, navigere mellom sider og ta skjermbilder.

Verktøyet er særlig nyttig når du vil teste hele flyter: innlogging, bestilling, skjemaer og kritiske brukerreiser. Det erstatter ikke enhetstester, men kompletterer dem der du må være sikker på at alt henger sammen i nettleseren.

Grunnoppsett: slik kommer du i gang i et eksisterende prosjekt

Det mest praktiske er å legge Playwright inn i et prosjekt som allerede har Node og en pakkebehandler som npm eller pnpm. Da kan du knytte det rett inn i de skriptene du allerede kjører daglig.

Fra rotmappen i prosjektet kan du typisk gjøre noe i denne retningen (tilpass til foretrukket pakkebehandler og rammeverk):

• Installer Playwright testrunner og typer
• La Playwright sette opp standardstruktur
• Kjør en første test for å se at alt fungerer

Struktur på testene: unngå kaos fra dag én

En ryddig mappestruktur gjør det mye lettere å vedlikeholde testene over tid. En enkel start kan være å samle alt i en egen testmappe, og skille på rene funksjonelle tester og mer komplette brukerreiser.

Det kan for eksempel se slik ut: en mappe for korte, fokuserte tester av enkeltkomponenter og en egen mappe for hele fløyer som registrering, kjøp eller admin-oppgaver. Poenget er at du raskt skal kunne finne igjen testen knyttet til delen av applikasjonen du jobber med.

Lokal kjøring: test mot riktig miljø

Det første valget du må ta er hvilket miljø Playwright skal teste mot. Vanligvis har du tre alternativer: lokalt dev-miljø (for eksempel server som kjører på localhost), et delt testmiljø, eller en bygget versjon som startes opp spesielt for testene.

For daglig utvikling er det mest praktisk å teste mot din lokale kjørende app. Playwright kan konfigureres til å anta at applikasjonen allerede kjører på en gitt port, eller til å starte den via et kommando-skript før testkjøringen.

Håndtering av data: lag tester som kan kjøres flere ganger

Mye frustrasjon med ende-til-ende-tester kommer fra testdata som “brukes opp”. En test som bare fungerer første gang den oppretter en bruker, er ikke spesielt nyttig i lengden.

Prøv derfor å lage tester som enten rydder opp etter seg, bruker unike verdier ved hvert løp (for eksempel tidsstempel i e-postadresse), eller kjører mot et miljø som kan resettes. Målet er at samme test skal kunne kjøres mange ganger på rad uten manuelle forberedelser.

Typiske feilkilder og hvordan du unngår dem

Mange problemer med Playwright kommer av at testene løper raskere enn applikasjonen. Komponenter er ikke ferdig lastet, nettverkskall ikke ferdig, eller animasjoner blokkerer elementer. Da ender du fort opp med flaky tester.

Bruk eksplisitte forventninger på ting som er synlige eller interaktive, i stedet for tilfeldige pauser. Det gjør testene mer stabile og raskere, fordi de avsluttes så snart siden er klar, ikke etter et vilkårlig antall sekunder.

Integrer i daglig arbeidsflyt: små steg, ofte

Playwright er mest verdifullt når det blir en naturlig del av måten du jobber på. Det krever at terskelen for å kjøre testene er lav, og at du slipper å huske kompliserte kommandoer eller oppsett hver gang.

En enkel tilnærming er å legge inn skript i pakkebehandleren din for vanlige operasjoner. For eksempel ett skript for å kjøre alle testene lokalt, og ett for å kjøre kun testene knyttet til en bestemt mappe eller et bestemt navn. Da kan du raskt få tilbakemelding mens du utvikler.

Når du bør ta steget videre til CI

Når du har noen stabile tester lokalt, er neste naturlige steg å kjøre dem automatisk i en CI-pipeline. Poenget er ikke å ha så mye som mulig i CI, men å beskytte de viktigste brukerreisene mot å bli ødelagt mellom hver deploy.

Før du gjør det, lønner det seg å sikre at testene er deterministiske lokalt, har forutsigbare data og ikke er avhengig av manuell input. Da slipper du mye feilsøking i et mer komplisert miljø senere.

En enkel sjekkliste før du satser videre på Playwright

Før du bygger videre på ende-til-ende-testene dine, kan det være nyttig å sjekke at grunnmuren er på plass. Det sparer deg for omarbeiding når antall tester vokser.

• Har du en fast mappestruktur for testene?
• Vet du hvilket miljø testene skal kjøre mot lokalt?
• Er testdataene laget slik at testene kan kjøres flere ganger?
• Bruker du forventninger i stedet for tilfeldige pauser?
• Er det enkelt å kjøre testene med ett eller to skript?

Når disse punktene er på plass, er du godt rigget til å la Playwright bli en pålitelig del av verktøykassen, i stedet for enda et verktøy som samler støv i repositoriet.