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, ingebouwd in Claude Code, Cursor, VS Code en GitHub Copilot. Het testtool werd stilletjes de standaard interface tussen AI agents en het web.

Waarom? Omdat je met data-testid test of je eigen label nog klopt. Met getByRole test je of je UI daadwerkelijk werkt, voor gebruikers, voor screenreaders, en nu ook voor AI agents. Drie vliegen in één selector. En je tests zijn net zo stabiel.

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. Uitgebracht in maart 2025, open source, en inmiddels de standaard manier waarop AI agents met websites werken.

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

Wanneer een AI agent moet begrijpen wat er op een pagina staat, maakt die geen screenshot. Die roept browser_snapshot aan, wat de accessibility tree van de browser retourneert. Dat is een YAML-geserialiseerde weergave van de pagina met alleen semantisch betekenisvolle elementen.

# 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:

Elk groot AI coding-tool heeft nu browsertoegang via Playwright MCP. Je website wordt niet meer alleen bezocht door gebruikers en crawlers, het wordt genavigeerd door AI agents met dezelfde tool 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 tegelijkertijd je UI, valideer je accessibility, en verifieer je dat AI agents je site kunnen navigeren. 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 wat agents zien. Als je testsuite slaagt met getByRole-selectors, heb je geverifieerd dat de accessibility tree correct is

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 schrijft direct tegen de accessibility tree. In plaats van te checken of een element in de DOM bestaat, verifieer je de semantische structuur die AI agents en schermlezers daadwerkelijk zien.

// 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

Dit is het test-equivalent van "wat je ziet is wat agents krijgen." Als je ARIA snapshot test slaagt, weet je precies wat een AI agent ziet wanneer die browser_snapshot aanroept via Playwright MCP. Het testoutputformaat en het agent-inputformaat zijn dezelfde YAML-structuur.

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:

Vier van de zes zijn direct op Playwright gebouwd. Alle zes gebruiken de accessibility tree. Het framework dat je koos voor testen is de runtime geworden voor AI agents.

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. Deze dienen als contract: als de snapshot slaagt, kunnen agents de pagina navigeren
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 47 checkpoints

Het Grotere Plaatje: Testen als AI Agent-Contract

Playwright-tests geschreven met accessibility-selectors zijn, functioneel gezien, een contract dat definieert wat AI agents op je site kunnen doen. Als je test zegt "klik op de In winkelwagen-knop," dan is dat een capability die je aan agents blootstelt.

Vergelijk het met WebMCP , het W3C-voorstel waarbij websites expliciet tools registreren voor AI agents. WebMCP doet het met tool-definities. Playwright MCP doet het impliciet via de accessibility tree. Ander mechanisme, zelfde uitkomst: je site wordt iets dat machines daadwerkelijk kunnen gebruiken.

Organisaties die investeerden in Playwright-testen met semantische selectors, of dat nu was voor accessibility-compliance, testingbest practices, of simpelweg omdat de docs het zeiden, bouwden per ongeluk het fundament voor AI agent-interactie. Dezelfde interface die software testbaar maakt, maakt het agent-ready. Niet by design. Gewoon door het werk goed te doen.

Conclusie

Playwright ging van Puppeteer-alternatief naar het populairste testframework naar de standaard browser-runtime 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 test je of je UI daadwerkelijk werkt, voor gebruikers, voor screenreaders, en voor AI agents. Drie vliegen in één selector. En je tests zijn net zo stabiel.

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