Waarom E2E-tests achterlopen
In een app vol workflows zoals Property Plan zitten de riskante bugs zelden in één component. Ze zitten in het pad door meerdere schermen: een melding die niet naar de volgende status kan, een formulier dat op mobiel zijn state kwijtraakt. Daar zijn end-to-end tests voor, en precies daarvoor zijn ze het traagst om te schrijven.
Een goede E2E-test schrijven betekent door de app klikken, stabiele selectors vinden, wachten op het juiste moment, en dat opnieuw doen als de UI verandert. Door die frictie loopt E2E-dekking meestal achter op de features.
Wat MCP toevoegt
Met het Model Context Protocol kan een AI-assistent tools gebruiken. De Playwright MCP-server is zo’n tool: de assistent krijgt een echte browser die hij kan openen, doorklikken en lezen, via de toegankelijkheidsboom in plaats van screenshots.
Dat verandert de loop. In plaats van zelf door een workflow te klikken en dat in code te vertalen, beschrijf ik het scenario, loopt de assistent door de app en review en vorm ik de test die hij voorstelt.
Hoe ik het gebruikte
Beschrijf het scenario
In gewone taal, vanuit de gebruiker: registreer een schademelding, wijs hem toe, sluit hem af.
Laat hem verkennen
De assistent opent de app, vindt elementen op rol en label, en meldt wat hij ziet, ook waar de flow niet doet wat ik beschreef.
Review het als elke andere code
De gegenereerde test krijgt dezelfde review als handgeschreven code: selectors op rol, geen vaste timeouts, één duidelijke assertion per stap.
Draai het in de pipeline
De test draait in CI met gewone Playwright. MCP gebruik je alleen bij het schrijven, niet bij het testen.
Waar ik op let
Een assistent schrijft graag een test die slaagt. Dat is niet hetzelfde als een test die faalt wanneer het moet. Ik breek de feature nog steeds één keer expres om de test rood te zien worden.
Toegankelijke markup betaalt zich dubbel uit. Dezelfde rollen en labels die schermlezergebruikers helpen, maken de app makkelijk navigeerbaar voor de assistent en de tests stabiel.