Playwright: Van Testrunner naar AI Agent-Interface

In 2017 bouwde Google Puppeteer om Chrome te automatiseren. In 2020 vertrokken de twee lead developers naar Microsoft en bouwden Playwright, zelfde idee maar cross-browser vanaf dag één. In april 2025 haalde Playwright Cypress in op npm downloads. Weer een testframework dat de framework-wars won. Of zo leek het.

Toen bracht Microsoft in maart 2025 Playwright MCP uit, een MCP-server die AI agents dezelfde browser laat bedienen als waarmee je tests schrijft. Binnen een jaar: 25.000+ GitHub stars, met integraties voor tools waaronder Claude Code, Cursor, VS Code en GitHub Copilot. Playwright was een belangrijke browserautomatiseringsoptie voor AI agents geworden.

Met getByRole test je of Playwright de UI via roles en toegankelijke namen kan vinden. Die signalen ondersteunen ook Playwright MCP en andere snapshot-afhankelijke agents, zonder volledige interactie of taaksucces te bewijzen.

Playwright in Cijfers

Wat begon als een Puppeteer-alternatief is het dominante browser-automatiseringsframework geworden. De cijfers liegen er niet om:

Wekelijkse npm downloads in miljoenen. Bron: npm registry. Playwright ging van 56K wekelijkse downloads in 2020 naar 34M+ in 2026. Meer dan 12.400 bedrijven gebruiken het, waaronder Amazon, Apple, Microsoft en NVIDIA.

Maar het cijfer dat er het meest toe doet staat niet op npm. Het zijn de 25.000+ stars op de Playwright MCP-repository, een apart project dat Playwright transformeerde van testtool naar AI agent-runtime.

Wat is Playwright MCP?

MCP (Model Context Protocol) is de open standaard voor het verbinden van AI-assistenten met externe tools. Playwright MCP is Microsoft's officiële MCP-server die AI agents een browser geeft die ze kunnen bedienen. Het verscheen in maart 2025 als opensource browserautomatiseringsoptie voor compatibele agents.

Het biedt 70+ tools georganiseerd in capability groups: navigatie, klikken, typen, formulieren invullen, tabbeheer, PDF-generatie en meer. Maar de belangrijkste tool is browser_snapshot.

browser_snapshot: Hoe Agents een Pagina Lezen

Binnen Playwright MCP biedt browser_snapshot de accessibility tree van de browser als een YAML-geserialiseerde weergave van semantisch betekenisvolle elementen. Andere browseragentsystemen kunnen ook de DOM, screenshots of een combinatie van modaliteiten gebruiken.

# browser_snapshot output voor een loginformulier
- heading "Welkom terug" [level=2]
- textbox "E-mail" [required] (ref=1)
- textbox "Wachtwoord" [required] (ref=2)
- button "Inloggen" (ref=3)
- link "Wachtwoord vergeten?" (ref=4)
- link "Account aanmaken" (ref=5)

Dat is het. Geen CSS-klassen, geen layout-divs, geen inline styles. Alleen wat de pagina bevat en wat je ermee kunt doen. Elk interactief element krijgt een referentienummer. De agent zegt "click ref 3" om in te loggen. Schoon, voorspelbaar, goedkoop in tokens.

Playwright MCP draait in twee modi:

De standaard is snapshot-modus. Niet vision. Blijkbaar zijn screenshots van websites niet de beste manier voor AI om ze te begrijpen, wie had dat gedacht.

Wie Gebruikt Playwright MCP?

Playwright MCP is geen niche-experiment. Het is geïntegreerd in de tools die de meeste developers dagelijks gebruiken:

Verschillende AI coding-tools hebben browsertoegang via Playwright MCP. In die workflows navigeert een agent je website met hetzelfde automatiseringsframework waarmee je test.

data-testid Is een Code Smell (Je Ruikt Het Alleen Nog Niet)

Met data-testid test je of je eigen label nog klopt. De test slaagt, prima. Maar je hebt niet geverifieerd dat een gebruiker die knop ook echt kan vinden, dat een screenreader hem kan aankondigen, of dat een AI agent weet dat hij bestaat. Je test je eigen boekhouding.

Met getByRole faalt je test als de button geen echte button is. Dat dwingt je om de markup te fixen. En die gefixte markup verschijnt in de accessibility tree, dezelfde boom die AI agents lezen via Playwright MCP's browser_snapshot.

De accessibility tree bevat geen test-attributen. Wanneer Playwright MCP browser_snapshot aanroept, bestaat je zorgvuldig geplaatste data-testid="submit-btn" simpelweg niet. Wat wél bestaat zijn rollen, labels en namen, exact wat getByRole en getByLabel opvragen.

// Je Playwright test
await page.getByRole('button', { name: 'In winkelwagen' }).click();
await page.getByLabel('E-mail').fill('user@example.com');
await page.getByRole('link', { name: 'Afrekenen' }).click();

// Wat een AI agent ziet via Playwright MCP browser_snapshot
// - button "In winkelwagen" (ref=12)
// - textbox "E-mail" (ref=15)
// - link "Afrekenen" (ref=18)

// Dezelfde selectors. Dezelfde elementen. Dezelfde accessibility tree.

De test-selector en de agent-selector zijn hetzelfde. Met getByRole test je UI-semantiek en bevestig je dat roles en names beschikbaar zijn voor snapshot-afhankelijke agents zoals Playwright MCP. Dat bewijst op zichzelf geen volledige navigatie of taaksucces. Met data-testid test je een string die je zelf verzonnen hebt.

Playwright's eigen documentatie duwt teams al jaren in deze richting. Hun locator-prioriteitsgids beveelt expliciet getByRole aan als eerste keuze en data-testid als laatste redmiddel. Destijds was de redenering "test zoals een gebruiker." Nu strekt de redenering zich uit tot "bouw voor agents."

Het Vliegwiel: Testen, Toegankelijkheid, Agent Readiness

Dit is wat er gebeurt als je Playwright met semantische selectors gebruikt:

1. Je schrijft Playwright-tests met accessibility-first selectors zoals getByRole, getByLabel en getByText
2. Dit dwingt toegankelijke HTML af. Als je getByRole-selector het element niet kan vinden, is het geen echte button. Je test faalt, dus je fixt de markup
3. Toegankelijke HTML produceert een rijke accessibility tree, dezelfde boom die AI agents consumeren via Playwright MCP
4. AI agents kunnen je site navigeren. Ze vinden knoppen, vullen formulieren in, volgen links en voltooien taken
5. Je tests valideren de semantiek die Playwright MCP aanbiedt. Als je testsuite slaagt met getByRole-selectors, heb je de relevante roles en accessible names geverifieerd

Teams met een solide Playwright-testsuite die semantische selectors gebruikt, hebben al twee dingen waarvan ze niet wisten dat ze ze hadden: toegankelijke interfaces en AI-agent-ready websites. Teams die testen skipten, of vertrouwden op visual regression tests en testid's? Geen van beide.

ARIA Snapshots: De Boom Zelf Testen

Playwright ging nog een stap verder met ARIA snapshot testing, een feature waarmee je assertions direct tegen een accessibility-weergave schrijft. In plaats van alleen te checken of een element in de DOM bestaat, verifieer je de semantische structuur die Playwright aan tests en snapshots aanbiedt.

// ARIA snapshot test — valideert de accessibility tree direct
await expect(page.getByRole('navigation')).toMatchAriaSnapshot(`
  - link "Home"
  - link "Producten"
  - link "Prijzen"
  - link "Contact"
`);

// Dit valideert:
// 1. Een navigatie-landmark bestaat
// 2. Het bevat vier links met exact deze namen
// 3. De accessibility tree is correct voor zowel schermlezers als AI agents

Als je ARIA snapshot test slaagt, heb je de YAML-structuur geverifieerd die Playwright MCP teruggeeft wanneer het browser_snapshot aanroept. Dit dekt die gestructureerde snapshot, terwijl de agent daarnaast context zoals screenshots of DOM-data kan gebruiken.

Playwright introduceerde ook Test Agents, ingebouwde AI die de accessibility tree gebruikt om automatisch tests te plannen, genereren en repareren. De planner verkent je app via accessibility snapshots, de generator schrijft tests met getByRole-selectors, en de healer repareert gebroken tests wanneer de UI verandert door de accessibility tree opnieuw te lezen. Het is agents helemaal naar beneden.

Voorbij Playwright MCP: Het Browser Agent-Landschap

Playwright MCP is niet de enige manier waarop AI agents het web browsen, maar het zette het patroon dat anderen volgen. Zo ziet het bredere landschap eruit:

Verschillende tools in deze vergelijking bouwen op Playwright of bieden accessibility snapshots, terwijl andere screenshots met gestructureerde browserdata combineren. Het framework dat je koos voor testen kan dus ook een browserworkflow voor agents ondersteunen.

Wat Dit Betekent voor je Team

Als je al Playwright gebruikt, ben je dichter bij AI agent readiness dan je denkt. Maar de specifieke manier waarop je het gebruikt maakt het verschil:

Praktische Stappen

1. Audit je locator-strategie. Grep je testsuite op data-testid vs getByRole. De verhouding vertelt je hoe agent-ready je tests (en je UI) zijn
2. Migreer kritieke paden eerst. Begin met je belangrijkste gebruikersflows: login, zoeken, checkout, registratie. Herschrijf die tests naar getByRole-selectors. Fix de HTML waar tests falen
3. Voeg ARIA snapshot tests toe. Voeg voor sleutelpagina's snapshot tests toe die de accessibility tree-structuur valideren. Een geslaagde snapshot bevestigt roles, names en states, maar bewijst geen volledige navigatie of taaksucces
4. Probeer Playwright MCP zelf. Installeer het in Claude Code of Cursor en richt een agent op je eigen site. Kijk wat die ziet. De gaten worden meteen duidelijk
5. Scan op AI agent readiness. Gebruik onze gratis scanner om semantische HTML, formulierlabels, koppenstructuur en interactieve surfaces te checken over 65 checkpoints

Het Grotere Plaatje: Testen als AI Agent-Contract

Playwright-tests met accessibility-selectors bieden een contract voor de roles, names en states waarnaar Playwright MCP kan verwijzen. Als je test de knop "In winkelwagen" via role en name vindt, kan dat semantische doel ook in een Playwright MCP-snapshot verschijnen. De test definieert niet alles wat een agent kan doen.

Vergelijk het met WebMCP , het W3C-voorstel waarbij websites expliciet tools registreren voor AI agents. WebMCP gebruikt tooldefinities. Playwright MCP biedt semantische browserdoelen via accessibility snapshots. Deze mechanismen bieden verschillende niveaus van structuur en geen van beide garandeert taaksucces.

Organisaties die investeerden in Playwright-tests met semantische selectors bieden al bruikbare roles en names aan Playwright MCP en andere snapshot-afhankelijke agents. Dat versterkt één interactiemodaliteit, naast DOM-toegang, screenshots en expliciete agentprotocollen.

Conclusie

Playwright ging van Puppeteer-alternatief naar een populair testframework en vervolgens naar een browser-runtime die via MCP beschikbaar is voor AI agents. Elke stap volgde logisch uit de vorige: cross-browser automatisering, accessibility-first selectors, en nu MCP-gebaseerde agent-besturing.

Met data-testid test je of je eigen label nog klopt. Met getByRole getByRole test lokalisering via roles en names en ondersteunt snapshot-afhankelijke agents, maar bewijst geen complete interactie of taaksucces. Het houdt je tests ook in lijn met hoe gebruikers en screenreaders bedieningselementen identificeren.

Test zoals een gebruiker, bouw voor een agent. Zelfde selector.

Bronnen

• Playwright — Microsoft's Browser Automation Framework — 80.000+ GitHub stars, 33M wekelijkse npm downloads
• Playwright MCP — Browser Automatisering voor AI Agents — 25.000+ GitHub stars, 70+ tools, uitgebracht maart 2025
• Playwright Locators Documentatie — Aanbevolen locator-prioriteit: getByRole eerst, data-testid als laatste redmiddel
• Playwright ARIA Snapshots — Accessibility tree-structuur direct testen
• Playwright Test Agents — AI-aangedreven testplanning, -generatie en -reparatie
• Simon Willison — Playwright MCP met Claude Code — Praktische gebruiksgids en authenticatiepatronen
• GitHub Blog — Debug Web Apps met Playwright MCP en Copilot
• GitHub Docs — MCP en Copilot Coding Agent — Playwright MCP automatisch geconfigureerd voor Copilot's coding agent
• TestDino — Playwright Marktaandeel 2025 — 45,1% QA-adoptiegraad, 235% groei jaar-op-jaar
• Fastly — AI Crawlers maken 80% van AI Bot-verkeer uit
• IsAgentReady: Hoe AI Agents je Website Zien — De Accessibility Tree Uitgelegd
• IsAgentReady: Wat is MCP? Het Model Context Protocol voor AI Agents
• IsAgentReady: Wat is WebMCP en waarom heeft je website het nodig