AI-kodeagenter som Claude Code, GitHub Copilot og Cursor kan skrive kode i minutter, men de har historisk set ikke kunnet se, hvad der rent faktisk sker i en browser. Det problem løser Playwright MCP. Serveren giver en AI-agent direkte adgang til en rigtig browser, så den kan klikke, udfylde felter, navigere og læse siden, før den konkluderer noget som helst. Microsoft har bygget serveren oven på Playwright, som allerede er et af de mest brugte testframeworks til web, og resultatet er en bro mellem sprogmodeller og et ægte browservindue.
Denne guide viser, hvordan du sætter Playwright MCP op fra bunden: Node.js, testprojektet, selve MCP-serveren og forbindelsen til fire forskellige AI-klienter. Du ender med et komplet testprojekt, som en AI-agent kan bruge til at udforske en side, generere en test og køre den i CI. Guiden er skrevet til udviklere, der allerede kender til npm og terminalen, men ikke nødvendigvis har rørt MCP før.
Mange danske og nordiske udviklingsteams har allerede taget AI-kodeagenter ind i den daglige arbejdsgang til selve kodeskrivningen, men browsertest bliver ofte overladt til manuelt klik-klik eller til testkode, der tager lang tid at vedligeholde. Playwright MCP lukker netop det hul, fordi agenten kan afprøve et helt flow, inden nogen overhovedet har skrevet en linje test. Det gør værktøjet relevant, uanset om du sidder i et lille startup-team eller i en større organisation med et dedikeret QA-spor. Bruger teamet allerede en AGENTS.md-fil til at styre agenters adfærd i repoet, kan I med fordel beskrive Playwright MCP-opsætningen der, så nye medarbejdere og nye agent-sessioner får den samme kontekst med det samme.
Guiden kræver ingen betalt licens og ingen skjulte forudsætninger ud over dem, du finder i tabellen nedenfor. Både Playwright og Playwright MCP er open source, og du kan følge alle tolv trin på en helt almindelig bærbar computer, uanset om den kører Windows, macOS eller Linux. Se flere guider til AI-drevne udviklerværktøjer i vores samlede oversigt over software og kodeværktøjer.
Hvad er Playwright MCP, og hvorfor stiger søgningerne på det nu
Playwright er Microsofts framework til browserautomatisering og end-to-end-test, og det seneste stabile spor er version 1.63.0, udgivet 4. september 2026. Playwright MCP er en separat, officiel pakke ved navn @playwright/mcp, som pakker Playwrights browserkontrol ind i Model Context Protocol (MCP). MCP er den åbne standard, som gør det muligt for en AI-agent at tilgå eksterne værktøjer, uden at udvikleren skal skrive en unik integration for hver model.
Det, der adskiller Playwright MCP fra ældre former for browserautomatisering, er, at agenten ikke kun ser et skærmbillede. Den får et struktureret udsnit af siden, kaldet et accessibility-snapshot, med roller, navne og tilstand for hvert element. En knap med teksten “Log ind” er for agenten ikke en klynge af pixels, men et objekt med rolle “button” og navn “Log ind”. Det gør agenten langt mere præcis, når den skal klikke det rigtige sted, og det er samtidig hurtigere end at analysere et billede for hver handling.
Interessen er steget markant, fordi de store kodeagenter i 2026 er begyndt at anbefale netop denne opsætning som standardvalg til browsertest. Claude Code, Cursor, Windsurf og VS Code kan alle pege på samme MCP-server, og fordi konfigurationen er identisk på tværs af klienterne, er den blevet en af de mest almindelige måder at give en agent “øjne” i browseren på. Resten af artiklen går trin for trin gennem opsætningen, med kommandoer du kan kopiere direkte.
Rent teknisk er en MCP-server et lille program, der taler et standardiseret protokolsprog med klienten, typisk over standard input og output eller over en lokal port. Klienten (for eksempel Claude Code) sender en forespørgsel om, hvilke værktøjer serveren stiller til rådighed, og serveren svarer med en liste, som i Playwright MCPs tilfælde blandt andet indeholder navigate, klik, snapshot og screenshot. Fra det øjeblik agenten kender værktøjerne, kan den selv vælge, hvornår den skal bruge dem, uden at du som udvikler skal skrive integrationskode mellem modellen og browseren.
Den samme protokol bruges også til helt andre formål end browserstyring, for eksempel filsystemadgang, databaseopslag eller interne API-kald (se vores guide til MCP-server-opsætning for en bredere gennemgang), men Playwright MCP er blevet et af de mest citerede eksempler, fordi behovet er så konkret genkendeligt. Enhver udvikler, der har prøvet at forklare en fejl for en kollega ved at sige “prøv selv at klikke rundt”, forstår med det samme værdien af, at en AI-agent kan gøre præcis det samme, blot hurtigere og uden at skulle vækkes klokken ni om morgenen.
Forudsætninger: software, versioner og adgang du skal bruge
Før du starter, skal maskinen opfylde nogle få krav. Playwright MCPs officielle installationsside kræver Node.js 18 eller nyere, og det er ikke en anbefaling, du kan springe over. Ældre Node-versioner fejler ofte stille under installationen af browser-binaries, og fejlbeskeden peger sjældent direkte på versionsproblemet.
| Komponent | Krav | Tjek-kommando |
|---|---|---|
| Node.js | Version 18 eller nyere | node --version |
| npm | Følger med Node.js-installationen | npm --version |
| Styresystem | Windows 10/11, macOS eller Linux | – |
| MCP-klient | Claude Code, Claude Desktop, Cursor eller VS Code | – |
| Diskplads | Ca. 1-2 GB til de tre browser-binaries | df -h |
| Terminaladgang | Bash, zsh eller PowerShell | – |
Du behøver ikke være Playwright-ekspert for at følge guiden, men du bør kende det basale npm-workflow: installere pakker, køre scripts og læse en terminalfejl uden at gå i panik. Har du allerede et Node-projekt, kan du springe projektoprettelsen over og gå direkte til trinnet, hvor MCP-serveren installeres.
Vælg desuden på forhånd, hvilken side eller hvilket system agenten skal øve sig på. Guiden bruger Playwrights egen offentlige demo, TodoMVC, fordi den er lavet specifikt til test og ikke indeholder rigtige brugerdata. Skal du senere pege agenten mod dit eget produkt, er det klogt at bruge et stagingmiljø i stedet for produktion, af grunde vi vender tilbage til i afsnittet om avancerede tips.
Trin 1-2: Installer Node.js og opret dit testprojekt
Start med at tjekke, om Node.js allerede sidder på maskinen, og om versionen er høj nok.
node --version
npm --versionViser kommandoen et tal under 18, skal du opgradere. Hent den nyeste LTS-udgave fra nodejs.org, eller brug en versionsstyring som nvm, hvis du arbejder på flere projekter med forskellige Node-krav samtidig. Når versionen er på plads, opretter du et nyt Playwright-testprojekt med det officielle init-script:
npm init playwright@latestScriptet spørger, om du vil bruge TypeScript eller JavaScript, hvor test-filerne skal ligge, og om GitHub Actions-workflow skal genereres automatisk. Svar TypeScript og ja til workflow, hvis du senere vil have testene til at køre i CI, som vi gør i trin 12. Har du allerede et eksisterende Node-projekt og kun vil tilføje test-runneren, kan du i stedet køre:
npm install -D @playwright/testTrin 3: Installer Playwright og de tre browser-motorer
Playwright styrer tre browser-motorer: Chromium, Firefox og WebKit. De skal hentes separat, fordi Playwright bruger patchede versioner, der er testet sammen med den specifikke Playwright-udgave. Installer alle tre med:
npx playwright installOutput ser typisk sådan ud, mens hver browser hentes:
Downloading Chromium 130.0.6723.31 (playwright build v1187) - 168 Mb
Downloading Firefox 141.0 (playwright build v1490) - 96 Mb
Downloading Webkit 19.2 (playwright build v2140) - 88.6 MbHar du kun brug for én browser, for eksempel fordi CI-serveren har begrænset diskplads, kan du installere målrettet:
npx playwright install chromium
npx playwright install firefox
npx playwright install webkitBemærk, at både Playwrights egen test-runner og den kommende MCP-server deler de samme browser-binaries. Du skal altså kun installere dem én gang, uanset om du bruger Playwright til klassisk testautomatisering, til MCP, eller til begge dele i samme projekt.
Arbejder du i et CI-miljø, hvor hver kørsel starter fra et frisk image, er det værd at cache selve browser-mappen mellem kørsler i stedet for at hente alle tre motorer hver gang. Playwrights installationsscript respekterer miljøvariabler til at pege binaries-cachen hen på en mappe, du selv kontrollerer, hvilket typisk barberer et par minutter af hver CI-kørsel, når cachen rammer.
Trin 4: Forskellen på Playwright og Playwright MCP
Playwright og Playwright MCP løser to forskellige problemer, selvom de deler kodebase og browser-motorer. Playwright alene er et testframework: du skriver kode, der navigerer og verificerer, og testen kører deterministisk hver gang. Playwright MCP vender rækkefølgen om. Her er det en AI-agent, der beslutter, hvad der skal ske i browseren, trin for trin, ud fra en instruktion skrevet i almindeligt sprog.
Et typisk forløb, når en agent bruger MCP-serveren, følger denne rækkefølge: agenten navigerer til en URL, beder om et snapshot af siden, finder det rigtige element ud fra rolle og navn, udfører en handling som klik eller udfyldning, og tager eventuelt et skærmbillede for at bekræfte resultatet. Det gentages, indtil opgaven er løst, eller agenten rapporterer en fejl tilbage.
| Handling | Hvad agenten kan gøre | Typisk brug |
|---|---|---|
| Navigate | Åbne en URL i browseren | Starte på en given side eller et flow |
| Snapshot | Læse siden som en struktureret accessibility-tree | Finde elementer uden at gætte på pixel-koordinater |
| Click | Klikke et element ud fra rolle og navn | Trykke på knapper, links og menupunkter |
| Fill | Udfylde et tekstfelt | Login-formularer, søgefelter, kontaktformularer |
| Select option | Vælge en værdi i en dropdown | Filtre, sprogvalg, betalingsmetoder |
| Screenshot | Tage et billede af siden eller et element | Visuel bekræftelse og fejlsøgning |
Den store fordel ved accessibility-baseret navigation frem for ren billedgenkendelse er hastighed og præcision. En agent, der skal finde login-knappen i et skærmbillede, skal tolke pixels og gætte koordinater. En agent, der får et snapshot med rollen “button” og navnet “Log ind”, kan pege direkte på elementet. Det reducerer antallet af fejlklik markant og gør testene mere stabile på tværs af kørsler.
Metoden trækker direkte på de samme ARIA-roller og tilgængelighedsattributter, som skærmlæsere har brugt i årevis til at gøre websider brugbare for synshæmmede. En side, der allerede er bygget med ordentlig semantisk HTML og korrekte roller, giver derfor et langt renere snapshot end en side fyldt med generiske div-elementer uden nogen rolle eller tekst. Det betyder i praksis, at arbejdet med at gøre en side tilgængelig og arbejdet med at gøre den AI-testbar er tæt forbundet. Sider med dårlig tilgængelighed er typisk også sværere for en agent at navigere pålideligt, og her kan MCP-serverens vision-tilstand fungere som en nødløsning, hvor agenten i stedet arbejder ud fra skærmbilleder og koordinater.
Trin 5: Installer selve Playwright MCP-serveren
Den officielle pakke hedder @playwright/mcp og vedligeholdes af Microsoft under samme GitHub-organisation som selve Playwright. Den anbefalede måde at køre den på er gennem npx, så du altid får den nyeste version uden at skulle opdatere manuelt:
npx @playwright/mcp@latestVil du hellere have en fast, global installation, for eksempel fordi firmaets netværk blokerer gentagne npx-downloads, kan du installere pakken globalt:
npm install -g @playwright/mcpBland ikke pakken sammen med tredjepartsservere som @executeautomation/playwright-mcp-server, som er et separat, community-drevet projekt. Det kan fungere fint, men det er ikke Microsofts officielle pakke, og konfigurationssyntaksen kan afvige. Guiden her bruger udelukkende den officielle @playwright/mcp-pakke.
Sidder du bag en virksomheds proxy eller et strengt npm-registry, kan første kørsel af npx fejle, fordi pakken ikke kan hentes. Tjek i så fald, at din npm-konfiguration peger på det rigtige registry, og at proxy-miljøvariablerne HTTP_PROXY og HTTPS_PROXY er sat korrekt i den terminal, hvor klienten starter serveren fra. Det er en af de mest almindelige årsager til, at en opsætning virker på en udviklers private bærbare, men ikke på en arbejdsmaskine bag firewall.
Trin 6-9: Forbind MCP-serveren til din AI-klient
Konfigurationen er stort set identisk på tværs af klienter, fordi alle bruger samme JSON-struktur. Den mindste fællesnævner ser sådan ud, og du kan genbruge den i næsten alle MCP-kompatible værktøjer:
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": ["@playwright/mcp@latest"]
}
}
}Hvor filen skal gemmes, og om du overhovedet behøver at skrive JSON selv, afhænger af klienten. Under følger opsætningen for de fire mest brugte værktøjer. Bruger dit team flere af dem samtidig, for eksempel Claude Code til eksplorativ test og VS Code til den daglige udvikling, kan du roligt registrere den samme server i alle fire. De deler ikke tilstand, så en fejlkonfiguration i den ene klient påvirker ikke de andre.
Hvilken klient der giver mest mening, afhænger af, hvordan teamet allerede arbejder. Sidder I meget i terminalen og foretrækker et CLI-drevet flow, passer Claude Code godt, fordi registreringen sker med én kommando uden at forlade terminalen. Arbejder I primært i en grafisk editor og vil have MCP-serveren tæt på den almindelige kodeeditor, er VS Code eller Cursor det naturlige valg. Claude Desktop er værd at overveje, hvis den, der skal udforske siden, slet ikke er udvikler, men for eksempel en QA-ansvarlig, der hellere vil skrive instruktioner i almindeligt sprog i en chatapp end at åbne en editor.
Claude Code
Har du ikke selve Claude Code sat op endnu, er det værd at gøre først. Claude Code har en indbygget CLI-kommando til at registrere MCP-servere, så du slipper for at redigere en fil manuelt:
claude mcp add playwright npx @playwright/mcp@latestKør kommandoen fra projektmappen. Bekræft, at serveren er registreret, ved at skrive /mcp inde i Claude Code, hvor “playwright” nu bør stå på listen over aktive servere.
Claude Desktop
I Claude Desktop skal du selv indsætte JSON-strukturen i konfigurationsfilen claude_desktop_config.json. Åbn filen, tilføj samme blok som ovenfor under mcpServers, gem, og genstart derefter Claude Desktop helt, så den nye konfiguration bliver læst ind. En almindelig fejl er at glemme genstarten, hvorefter serveren ikke dukker op, selvom filen ser korrekt ud.
Cursor
Vores Cursor-opsætningsguide dækker den grundlæggende installation, hvis du starter helt fra bunden. I Cursor foregår MCP-opsætningen gennem brugerfladen. Gå til Cursor Settings, vælg MCP, og klik på “Add new MCP Server”. Vælg servertypen “command”, og indtast:
npx @playwright/mcp@latestGiv serveren et navn, for eksempel “playwright”, og gem. Cursor omsætter selv dit input til den samme JSON-struktur i baggrunden.
VS Code
VS Code kan registrere serveren direkte fra terminalen uden at åbne indstillingerne:
code --add-mcp '{"name":"playwright","command":"npx","args":["@playwright/mcp@latest"]}'Kommandoen virker på Windows, macOS og Linux, så længe code er tilgængelig i din PATH. Er det ikke tilfældet, skal du først køre kommandoen “Shell Command: Install ‘code’ command in PATH” fra VS Codes kommandopalet.
Uanset hvilken klient du vælger, er det værd at bruge to minutter på at bekræfte opsætningen, før du går videre. De fleste klienter har en form for MCP-oversigt i indstillingerne eller i en kommando som /mcp, hvor en aktiv server vises med grøn status. Er statussen rød eller fraværende, skal du ikke gå videre til næste trin, for fejlen forplanter sig sjældent tydeligt, den viser sig bare som en agent, der “ikke kan se browseren”.
Trin 10: Kør din første AI-styrede browsersession
Når serveren er registreret i din klient, er den nemmeste måde at teste forbindelsen på at give agenten en helt konkret opgave i almindeligt sprog. Skriv for eksempel i Claude Code eller Cursor: “Åbn https://demo.playwright.dev/todomvc, tilføj en opgave med teksten Køb mælk, og bekræft, at den optræder på listen.” Agenten bør nu selv navigere, tage et snapshot, finde inputfeltet og indtaste teksten.
Bag kulissen vil agentens snapshot-kald typisk returnere noget i stil med dette udsnit af accessibility-træet:
- textbox "What needs to be done?" [ref=e14]
- list "todo-list"
- listitem
- checkbox [unchecked] [ref=e21]
- text "Køb mælk"
- button "Delete" [ref=e23]Det er netop den strukturerede output, der gør, at agenten kan pege præcist på feltet “What needs to be done?” i stedet for at gætte et koordinatsæt i et skærmbillede. Virker det ikke første gang, er fejlen næsten altid i selve MCP-registreringen, ikke i browserinstallationen, så gå tilbage til trin 6-9 og tjek, at klienten er genstartet efter konfigurationen blev gemt.
Prøv derefter en lidt mere krævende opgave, for eksempel et login-flow: “Gå til demosiden, klik på login-knappen, udfyld et testbrugernavn og adgangskode, og bekræft, at siden viser en fejlmeddelelse, når felterne er tomme.” En god agent vil selv opdage, at den først skal tage et snapshot for at finde de rigtige felter, dernæst udfylde dem, og til sidst læse fejlbeskeden fra et nyt snapshot i stedet for at gætte på, om handlingen lykkedes. Det er denne evne til selv at planlægge flere trin, der gør MCP-opsætningen væsentligt mere robust end simple, forudskrevne scripts.
Trin 11: Byg et komplet testprojekt fra bunden
Nu hvor forbindelsen virker, kan du lade agenten generere en rigtig, deterministisk Playwright-test ud fra den udforskning, den lige har lavet. Bed agenten om: “Skriv en Playwright-test i TypeScript, der åbner TodoMVC-demoen, tilføjer opgaven Køb mælk, markerer den som færdig, og verificerer at den har klassen completed.” Resultatet er en almindelig test-fil, som ikke længere kræver MCP-serveren for at køre, fordi den nu er skrevet som fast kode.
En typisk fil, agenten producerer, ser sådan ud, gemt som tests/todo.spec.ts:
import { test, expect } from '@playwright/test';
test('tilføjer og fuldfører en opgave', async ({ page }) => {
await page.goto('https://demo.playwright.dev/todomvc');
const input = page.getByPlaceholder('What needs to be done?');
await input.fill('Køb mælk');
await input.press('Enter');
const item = page.getByText('Køb mælk');
await expect(item).toBeVisible();
const checkbox = page.getByRole('checkbox');
await checkbox.check();
const listItem = page.locator('li', { hasText: 'Køb mælk' });
await expect(listItem).toHaveClass(/completed/);
});Projektets konfigurationsfil, playwright.config.ts, som blev genereret automatisk i trin 2, bestemmer, hvilke browsere testen kører i, og hvor lang timeout-grænsen er. En minimal, men produktionsklar version ser sådan ud:
import { defineConfig, devices } from '@playwright/test';
export default defineConfig({
testDir: './tests',
timeout: 30_000,
retries: 1,
projects: [
{ name: 'chromium', use: { ...devices['Desktop Chrome'] } },
{ name: 'firefox', use: { ...devices['Desktop Firefox'] } },
{ name: 'webkit', use: { ...devices['Desktop Safari'] } },
],
});Kør testen lokalt for at bekræfte, at den agent-genererede kode rent faktisk består, uafhængigt af MCP-serveren:
npx playwright testDet er denne arbejdsgang, der gør Playwright MCP interessant ud over selve demoen. Agenten udforsker og eksperimenterer interaktivt, men slutresultatet er almindelig, versioneret testkode, som resten af teamet kan læse, redigere og køre uden nogensinde at have brugt MCP-serveren selv.
Projektstruktur
Et færdigt, minimalt projekt fra denne guide ender typisk med en struktur, der ser sådan ud:
mit-projekt/
├── tests/
│ └── todo.spec.ts
├── playwright.config.ts
├── package.json
├── .github/
│ └── workflows/
│ └── playwright.yml
└── playwright-report/Mappen playwright-report/ bliver genereret automatisk, hver gang testene kører, og indeholder en HTML-rapport med skærmbilleder fra eventuelle fejl. Åbn rapporten lokalt med:
npx playwright show-reportDet er langt hurtigere end at lede efter fejlen i rå terminaltekst, især når en test fejler på kun én af de tre browser-motorer.
Trin 12: Kør testene automatisk i CI/CD
Testprojektet er kun halvt færdigt, hvis det kun kører på din egen maskine. Da du oprettede projektet i trin 2, blev der tilbudt en GitHub Actions-workflow, og den ligger normalt i .github/workflows/playwright.yml. En typisk version installerer afhængighederne, henter browserne og kører testene ved hvert push:
name: Playwright Tests
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20
- run: npm ci
- run: npx playwright install --with-deps
- run: npx playwright test
- uses: actions/upload-artifact@v4
if: always()
with:
name: playwright-report
path: playwright-report/
retention-days: 14Flaget --with-deps er vigtigt på Linux-runnere, fordi det installerer de system-biblioteker, browserne har brug for ud over selve binaries. Springer du det over, fejler CI-kørslen typisk med en fejl om manglende delte biblioteker, selvom den samme kommando virker fint på din lokale macOS- eller Windows-maskine.
Bemærk, at workflowet ovenfor kører den faste, agent-genererede test fra trin 11, ikke selve MCP-serveren. Det er med vilje. MCP-serveren er tænkt som et udforskningsværktøj til dig og din agent, mens CI-kørslen skal være hurtig, deterministisk og uafhængig af, om en sprogmodel er tilgængelig lige nu. Vil du alligevel lade en agent køre eksplorative tjek som en del af pipelinen, bør det være et separat, ikke-blokerende job, så en langsom eller usikker agent-tur ikke vælter hele buildet.
Til daglig lokal udvikling er det ofte hurtigere kun at køre testene i Chromium, mens hele CI-pipelinen kører alle tre browser-motorer, inden en pull request merges. Den arbejdsdeling giver dig hurtig feedback, mens du skriver og tilretter testen, og fuld dækning, lige før koden lander på hovedgrenen. Retry-indstillingen i playwright.config.ts, som vi satte til 1 i eksemplet ovenfor, er en hjælp mod ægte flaky tests, men den bør ikke bruges til at skjule en test, der reelt afslører en timing-fejl i selve applikationen.
Playwright MCP vs. Selenium og Cypress i 2026
Selenium og Cypress er stadig udbredte, men de løser en anden opgave end Playwright MCP. Selenium bygger på WebDriver-standarden og har det bredeste økosystem af sprog og browser-grids, men der findes ingen officiel, Microsoft-vedligeholdt MCP-server til Selenium på niveau med Playwrights. Cypress har en stærk, interaktiv test-runner, som frontend-teams ofte foretrækker til hurtig feedback, men arkitekturen er mere lukket omkring browserkonteksten, hvilket gør multi-tab- og multi-browser-scenarier sværere at styre.
| Egenskab | Playwright MCP | Selenium | Cypress |
|---|---|---|---|
| Browserunderstøttelse | Chromium, Firefox og WebKit | Bredt, via WebDriver-implementeringer | Primært Chromium-familien |
| Officiel AI-agent-integration | Ja, via Microsofts @playwright/mcp | Ingen tilsvarende officiel MCP-server | Ingen tilsvarende officiel MCP-server |
| Navigationsmodel | Accessibility-snapshot plus auto-wait | WebDriver-kommandoer | Kommandokæder med automatisk retry |
| Multi-tab og multi-kontekst | Understøttet direkte | Understøttet, men mere manuelt | Mere begrænset i standardopsætning |
| Bedst til | AI-assisteret testgenerering og udforskning | Store, sprogblandede test-grids | Hurtig frontend-feedback lokalt |
Den praktiske konklusion er, at Selenium stadig vinder, hvis organisationen allerede har investeret tungt i WebDriver-infrastruktur og skal understøtte mange forskellige sprog. Cypress vinder, hvis teamet primært vil have en hurtig, interaktiv udviklingsoplevelse til frontend. Playwright MCP vinder, når kravet konkret er, at en AI-agent selv skal kunne styre en browser og læse siden struktureret, uden at udvikleren forinden har skrevet en eneste linje testkode.
De tre værktøjer udelukker i øvrigt ikke hinanden. Flere teams kører videre med en eksisterende Selenium- eller Cypress-testsuite til regressionstest, mens de samtidig bruger Playwright MCP som et separat, eksplorativt lag, hvor en agent afprøver nye flows og forslår testcases, før et menneske beslutter, om de skal ind i den faste suite. Det kræver ingen migrering af eksisterende kode, fordi MCP-serveren kører som et selvstændigt værktøj ved siden af, ikke som en erstatning for det testframework, teamet allerede har investeret i.
5 faldgruber, du skal undgå
De fleste problemer med Playwright MCP opstår ikke i selve browserautomatiseringen, men i de kedelige detaljer omkring miljø, brugerrettigheder og versioner. Her er de fem, der oftest sender udviklere på en unødvendig fejlsøgningstur.
- At springe Node-versionen over. Playwright MCP kræver Node.js 20 eller nyere. Kører du en ældre version, kan installationen se ud til at lykkes, men serveren fejler først, når klienten forsøger at starte den.
- At blande officiel og tredjeparts MCP-server sammen. Pakken
@playwright/mcper Microsofts egen. Community-projekter som@executeautomation/playwright-mcp-serverbruger en anden kommando og en anden konfigurationssyntaks, så kopierer du eksempler fra det forkerte projekt, fejler registreringen. - At glemme at genstarte klienten. Både Claude Desktop og VS Code cacher deres MCP-konfiguration ved opstart. Redigerer du filen, mens appen kører, dukker serveren ikke op, før du lukker og åbner appen igen.
- At installere browserne som forkert bruger. Kører du
npx playwright installmed sudo på én konto og starter derefter MCP-klienten under en anden bruger, finder klienten ikke binaries, fordi de ligger i en cache-mappe, den ikke har adgang til. Løsningen er at holde sig til én bruger gennem hele opsætningen, fra installation til den klient, der senere starter serveren. - At stole blindt på agentens første forsøg. En agent, der udforsker en side interaktivt, kan finde på at klikke forkert, især på sider med cookie-bannere eller modaler, der overlapper det egentlige indhold. Læg altid den genererede test igennem en manuel gennemlæsning, før den committes, ligesom du ville med kode skrevet af en ny kollega, og kør den mindst én gang selv, inden den ryger ind i en delt gren.
Fejlfinding: 8 problemer og hvordan du løser dem
Når noget går galt med Playwright MCP, ligger fejlen næsten altid i en af tre kategorier: miljøet (Node-version, brugerrettigheder), registreringen (JSON-konfiguration, genstart af klient) eller selve browserinteraktionen (timing, tvetydige elementer). Tabellen herunder samler de otte problemer, som oftest rapporteres, sammen med den mest sandsynlige årsag og den hurtigste løsning.
| Problem | Sandsynlig årsag | Løsning |
|---|---|---|
| “Executable doesn’t exist” | Browser-binaries er ikke installeret i det miljø, der starter serveren | Kør npx playwright install igen i samme terminal og under samme bruger |
| Serveren vises ikke i klienten | Forkert JSON-struktur, eller klienten er ikke genstartet | Valider JSON’en, tjek at command kun indeholder “npx”, og genstart appen |
| “npx cannot resolve the package” | Firmaets netværk kræver eksplicit godkendelse af nye pakker | Kør med npx --yes @playwright/mcp@latest |
| Timeout ved klik eller navigation | Siden er ikke færdig med at loade, eller et cookie-banner blokerer elementet | Bed agenten om et nyt snapshot først, og luk eventuelle overlejringer eksplicit |
| Permission denied under browserinstallation | Installation kørt med en anden bruger end den, der starter klienten | Installer og kør under samme konto, undgå at blande sudo og almindelig npm |
| CI fejler med manglende delte biblioteker | --with-deps blev ikke brugt på en Linux-runner | Tilføj flaget: npx playwright install --with-deps |
| Agenten klikker det forkerte element | Siden har flere elementer med samme eller lignende navn | Bed agenten om et nyt snapshot, og pege på det konkrete ref, ikke kun teksten |
| Node.js er for gammel | Systemet kører stadig Node 16 eller 18 | Opgrader til Node 20+, eller skift version med nvm, og kør node --version igen |
Avancerede tips til produktion
Når den grundlæggende opsætning virker, er der en håndfuld justeringer, der gør forskellen mellem et sjovt eksperiment og noget, teamet reelt kan stole på i hverdagen. Kør serveren headless i CI og på servere uden skærm, så du sparer ressourcer og undgår afhængigheder til et grafisk miljø. På en Linux-server uden display skal du enten bruge headless-tilstand som standard eller sætte en virtuel framebuffer op, hvis en afhængighed kræver et rigtigt vindue.
Headless-tilstand betyder, at browseren kører uden et synligt vindue, hvilket er både hurtigere og mere ressourcelet end en fuldt gengivet skærm. Til daglig, eksplorativ brug med en agent kan det dog være værdifuldt midlertidigt at køre headed, altså med et synligt vindue, så du selv kan følge med i, hvad agenten rent faktisk gør, mens du stadig bygger tillid til, at den klikker de rigtige steder.
Arbejder du bag en firewall eller skal teste sider, der kun er tilgængelige gennem et specifikt IP-udgangspunkt, kan Playwright konfigureres til at rute trafik gennem en proxy på samme måde som almindelig Playwright-test. Det er særligt relevant, hvis agenten skal teste interne systemer, som ikke er offentligt tilgængelige fra CI-serverens netværk.
Til teams med flere projekter er det værd at pinne en konkret version af @playwright/mcp i stedet for at bruge @latest i CI-miljøer. Det gør kørsler reproducerbare, fordi du undgår, at en ny udgivelse af MCP-serveren ændrer adfærd midt i en sprint. Brug @latest lokalt, mens du udforsker, og skift til et fast versionsnummer, når konfigurationen låses fast til et team-repo.
Endelig er det en god vane at lade agenten arbejde i et isoleret testmiljø eller mod en staging-server frem for produktion. En agent, der udforsker interaktivt, kan komme til at oprette testdata, slette en rigtig bruger eller trigge et rigtigt betalingsflow, hvis den peges direkte på et produktionsmiljø uden rækværk.
Hold også styr på, hvor mange handlinger du lader agenten tage i træk, uden at du selv kigger med. Hver navigate, snapshot og klik er en runde til den bagvedliggende sprogmodel, og en agent, der er gået i en løkke på en side med uendelig scroll eller et gentaget cookie-banner, kan nå at bruge overraskende mange runder, før den giver op. Sæt derfor en fornuftig grænse for, hvor lang tid eller hvor mange trin agenten må bruge på én opgave, især hvis den kører autonomt uden nogen, der følger med live.
Kører agenten i en isoleret container, kan vores guide til dev containers til AI-agenter give inspiration til at holde både MCP-serveren og agenten adskilt fra din almindelige udviklingsmaskine. Undgå desuden at lægge adgangskoder eller API-nøgler direkte ind i den instruktion, du giver agenten. Brug i stedet miljøvariabler eller et separat test-login, som kun har adgang til testdata, på samme måde som du allerede gør det i almindelige CI-pipelines. Det begrænser skaden, hvis en log eller en fejlrapport ved et uheld bliver delt med nogen, der ikke burde se den.
Ofte stillede spørgsmål om Playwright MCP
Er Playwright MCP gratis at bruge?
Ja. Både Playwright og den officielle MCP-server er open source og gratis. Du betaler kun for den AI-model, du forbinder den med, hvis den modeltjeneste selv har en pris.
Kræver det, at jeg kan TypeScript?
Nej. Du kan bruge MCP-serveren udelukkende gennem naturligt sprog i din AI-klient. TypeScript bliver først relevant, når du (eller agenten) genererer en fast, deterministisk test, du vil committe til repoet.
Kan jeg bruge Playwright MCP med GitHub Copilot?
Ja, så længe Copilot-klienten understøtter MCP-registrering. Konfigurationen følger samme standard-JSON som Claude Desktop og Cursor, men det præcise sted, du indsætter den, afhænger af hvilken editor du kører Copilot i.
Virker det på Linux uden grafisk skærm?
Ja, men du skal køre browserne headless. Mangler et bibliotek grafisk understøttelse, viser fejlbeskeden typisk direkte, hvilken afhængighed der mangler, og den løses normalt ved at installere med --with-deps. Det samme gælder, hvis du kører opsætningen i en container, hvor de underliggende systembiblioteker heller ikke er installeret som standard.
Hvad er forskellen på snapshot-tilstand og vision-tilstand?
Snapshot-tilstand er standard og bruger accessibility-træet, som beskrevet tidligere i artiklen. Vision-tilstand lader i stedet agenten arbejde ud fra skærmbilleder og koordinater, hvilket kan være nødvendigt på sider med dårlig eller manglende accessibility-mærkning, men det er generelt langsommere og mindre præcist.
Kan flere udviklere dele samme MCP-konfiguration?
Ja. Gemmer du konfigurationen i en delt fil i repoet, for eksempel en projekt-specifik MCP-opsætning i stedet for kun den personlige klientkonfiguration, kan hele teamet bruge samme opsætning uden at genopfinde den hver gang.
Hvad sker der, hvis to agenter forsøger at bruge browseren samtidig?
Hver MCP-server-instans styrer typisk sin egen browserkontekst, så to adskilte klient-sessioner kolliderer ikke med hinanden, medmindre I bevidst har peget dem på samme, delte browserproces. Skal flere agenter arbejde parallelt, er det enklest at give hver af dem sin egen serverinstans frem for at dele én session, så resultaterne ikke bliver blandet sammen.
Skal jeg bekymre mig om sikkerhed, når en agent styrer en rigtig browser?
Ja. En agent med browseradgang kan i princippet navigere til og interagere med enhver side, browseren har adgang til. Peg derfor kun agenten mod testmiljøer eller sider, du har godkendt, og undgå at give den adgang til en session, der er logget ind med et produktionsprivilegeret login.
Hvorfor genererer agenten en anden test, end jeg forventede?
Agenten bygger testen ud fra det, den rent faktisk observerede i sit snapshot, ikke ud fra din mentale model af siden. Var din instruktion tvetydig, eller har siden flere lignende elementer, kan agenten vælge et andet element end det, du havde i tankerne. Gør instruktionen mere konkret, eller peg direkte på elementets tekst og position.
Kan jeg køre flere MCP-servere sammen med Playwright MCP?
Ja. mcpServers-objektet i konfigurationen kan indeholde flere navngivne servere samtidig, for eksempel en til Playwright, en til filsystemadgang og en til et internt API. Klienten holder dem adskilt ud fra navnet, du har givet hver server, så der er ingen konflikt, så længe navnene er forskellige.
