Voor een volledige werking plaatst deze website cookies op uw computer. Daarnaast worden cookies geplaatst voor het bijhouden van bezoekersgedrag binnen Google Analytics. Deze informatie helpt ons bij het verbeteren van onze website. De cookies bevatten anonieme informatie en blijven maximaal 2 jaar in uw browser aanwezig. Lees meer
Het schrijven van een goede E2E-test met een degelijke page object, correcte locators, gedeelde fixtures, naleving van lintregels en een review volgens de huidige framework best practices kost een senior engineer één tot twee uur per test. Voor een complexe applicatie met tientallen kritieke flows werkt de rekensom zelden in het voordeel van testen.
Dat veranderde toen we AI begonnen te gebruiken als actieve deelnemer bij het schrijven en onderhouden van onze E2E-testsuites. In meerdere projecten gebruiken we nu Claude Code, een AI-agent van Anthropic voor software-engineering, samen met Playwright en TypeScript om geautomatiseerde testdekking op te bouwen in een tempo dat eerder niet haalbaar was.
Unit- en integratietests verifiëren dat afzonderlijke codeonderdelen in isolatie werken. Ze zijn snel en populair bij ontwikkelaars, maar ze kunnen niet de bredere vraag beantwoorden die voor een gebruiker telt: werkt de volledige flow, van begin tot eind, in een echte browser?
In complexe webapplicaties beslaan de meest kritieke paden – zoals meerstapsworkflows, externe integraties en rijke UI-componenten – meerdere lagen. Een bewerking kan starten in een kalender, door een formulier gaan met dropdown-afhankelijkheden en eindigen met een gegenereerd document dat de juiste regels moet bevatten. Een unit test kan een regressie in die keten niet detecteren. Een handmatige tester wel, maar niet bij elke pull request, niet in elke browser en niet zonder dat dit op termijn veel extra werk oplevert.
E2E-tests vullen dat gat door exact te simuleren wat een echte gebruiker doet: de browser openen, inloggen, navigeren, formulieren invullen en controleren of de juiste elementen op het scherm verschijnen.
Het proces begint met het schrijven van een gedetailleerd CLAUDE.md-instructiebestand in de root van het testproject. Dit bestand wordt door Claude Code bij het begin van elke sessie gelezen en legt de conventies van het project vast: de locatorhiërarchie, naamgevingsregels, het page object model, verboden patronen en de structuur van de CI-pipeline.
De prompts die goed werken zijn beschrijvingen in de stijl van een handmatige testcase:
"Test dat een gebruiker een nieuwe taak kan aanmaken door het onderwerp, de beschrijving en de vervaldatum in te vullen, een ontvanger te selecteren via een dropdown, op te slaan en vervolgens te verifiëren dat de taak verschijnt in het accordionpaneel onder het juiste dier."
Claude leest dit samen met het instructiebestand en genereert een page object met private read-only locators, een fixture entry en een spec-bestand dat de Arrange-Act-Assert-structuur volgt met test.step()-blokken – precies zoals het team dit handmatig zou schrijven.
Voor pagina’s die al een page object hebben, verwijst de prompt daarnaar:
"Breid de bestaande TaskPage uit om een bewerkflow toe te voegen via het contextmenu."
Claude leest het bestaande bestand, volgt de bestaande patronen en voegt alleen toe wat nodig is, zonder refactoring, nieuwe abstracties of scope creep.
Wanneer een gegenereerde test bij de eerste run faalt, wordt de foutoutput teruggegeven aan Claude. Hij leest de fout, bepaalt of het probleem ligt bij een locator, timing of logica en stelt een gerichte oplossing voor. Dit iteratieve proces verloopt aanzienlijk sneller wanneer AI deel uitmaakt van de loop dan wanneer failures handmatig worden geanalyseerd.
Voorbeeld: als een locator nog niet bestaat in de applicatie, signaleert Claude dit en stelt voor om een data-testid-attribuut toe te voegen aan de Angular-template. Dit houdt de testcode schoon en verbetert tegelijkertijd de testbaarheid van de applicatie.
