End-to-endtests schrijven met AI.

Op meerdere projecten gebruiken we nu Claude Code, de coding agent van Anthropic, samen met Playwright en TypeScript. Het resultaat is geautomatiseerde testdekking in een tempo dat we eerder niet haalden.

Wat het team eraan heeft

• Regressiebescherming. Een test die één keer is geschreven, draait bij elke release.
• Snellere feedback. Een kapotte flow komt meteen naar voren in CI, niet dagen later in een QA-sessie.
• Vertrouwen om te releasen. Een groene suite betekent dat het team kan deployen zonder angst voor stille regressies.
• Consistentie. Locatorstrategie, stapnamen en de structuur van page objects zijn in de hele suite hetzelfde.

Waarom end-to-endtests ertoe doen

Unit- en integratietests controleren of losse stukken code op zichzelf werken. Ze zijn snel en developers houden ervan, maar ze beantwoorden niet de vraag die voor een gebruiker telt: werkt de hele flow, van begin tot eind, in een echte browser?

In een complexe webapplicatie lopen de kritieke paden door veel lagen: meerstapsworkflows, externe koppelingen, rijke UI-componenten. Een bewerking kan beginnen in een kalender, door een formulier met afhankelijke dropdowns gaan en eindigen in een gegenereerd document dat de juiste regels moet bevatten. Een unittest vangt een regressie in die keten niet. Een handmatige tester wel, maar niet bij elke pull request, niet in elke browser, en niet zonder dat het werk zich opstapelt.

End-to-endtests dichten dat gat. Ze doen precies wat een gebruiker doet: de browser openen, inloggen, navigeren, formulieren invullen en controleren of de juiste dingen op het scherm verschijnen.

Hoe het werkt

Het begint met een gedetailleerd CLAUDE.md-instructiebestand in de root van het testproject. Claude Code leest het aan het begin van elke sessie. In het bestand staan de conventies van het project: de locatorhiërarchie, naamgevingsregels, het page object model, verboden patronen en de opbouw van de CI-pipeline.

Een test toevoegen

1. Beschrijf de te testen user flow in gewone taal.
2. Claude genereert het page object, de fixture-registratie en het spec-bestand op basis van onze instructies.
3. De tests draaien. Fouten worden in dezelfde sessie geanalyseerd en opgelost.
4. npm run lint draait automatisch. Elk issue is opgelost voordat de sessie eindigt.
5. Claude controleert de implementatie via een MCP-integratie tegen de actuele Playwright-documentatie en past aan wat verouderd is.

Prompts die werken

De prompts die werken, lezen als een handmatige testcase:

“Test dat een gebruiker een nieuwe taak kan aanmaken door onderwerp, beschrijving en vervaldatum in te vullen, een ontvanger te kiezen uit een dropdown, op te slaan en daarna te controleren dat de taak verschijnt in het accordionpaneel onder het juiste dier.”

Claude leest dit samen met het instructiebestand en maakt een page object met private read-only locators, een fixture-entry en een spec-bestand in Arrange-Act-Assert-structuur met test.step()-blokken. Het is wat het team met de hand zou schrijven.

Voor een pagina die al een page object heeft, verwijst de prompt daarnaar: “Breid de bestaande TaskPage uit met een bewerkflow via het contextmenu.” Claude leest het bestaande bestand, volgt de patronen en voegt alleen toe wat nodig is, zonder refactoring, nieuwe abstracties of scope creep.

Als een test faalt

Faalt een gegenereerde test bij de eerste run, dan gaat de foutuitvoer terug naar Claude. Hij leest de fout, bepaalt of het probleem bij een locator, de timing of de logica zit, en stelt een gerichte oplossing voor. Die lus gaat veel sneller met AI erin dan wanneer fouten met de hand worden uitgezocht.

Bestaat een locator nog niet in de applicatie, dan zegt Claude dat en stelt hij een data-testid-attribuut in de Angular-template voor. De testcode blijft schoon, en de applicatie wordt als bijeffect beter testbaar.

Technische basis

• Page objects. De UI zit in een klasse met private read-only locators en publieke actie- en assertiemethoden.
• Custom fixtures. Dependency injection regelt setup en authenticatie vóór elke test.
• Locatorhiërarchie. Eerst testId, dan role, dan label of placeholder.
• Testdata staat in JSON-bestanden met unieke ID’s, zodat tests parallel kunnen draaien.
• CI. Azure DevOps draait de suite parallel met retries, met rapportage voor de pipeline-dashboards.

Wat het oplevert

• Dekking. Minder werk per test laat meer tijd over voor de kritieke flows, en de applicatie wordt stabieler.
• Regressiedetectie. Kritieke flows draaien bij elke commit.
• Onboarding. Nieuwe teamleden lezen de suite om te leren hoe functies zich horen te gedragen.
• Snellere UI-wijzigingen. Een wijziging blijft beperkt tot zijn page object, dus updates zijn snel en voorspelbaar.