Is het nog relevant om AI te gebruiken voor het schrijven van unit tests? Absoluut. Maar de vraag die daar direct achteraan komt is interessanter: is het nog relevant om strikte coverage-thresholds te hanteren nu AI moeiteloos tests genereert? Ik denk het wel, al zou ik er niet meer zo op hameren als we een paar jaar geleden deden.

Het probleem met coverage-thresholds in een AI-workflow

Wanneer je een agentic AI een harde coverage-eis meegeeft, gebeurt er iets voorspelbaars: de AI gaat elke regel code testen. Niet omdat dat zinvol is, maar omdat dat de snelste route naar het gevraagde percentage is. Het resultaat is een berg unit tests waarvan een flink deel weinig toevoegt. Denk aan tests op triviale getters, tests die implementatiedetails vastleggen in plaats van gedrag, en tests die bij elke refactor breken.

Die berg tests heeft reële kosten:

  • Pipeline-tijd: elke test draait bij elke commit, elke PR en elke deploy. Een pipeline die van vijf naar vijftien minuten groeit, vertraagt het hele team.
  • Lokale feedback: ontwikkelaars draaien de suite minder vaak als die traag is. Dat ondermijnt precies het doel van de tests.
  • Ecologische impact: CI-minuten zijn rekenkracht. Duizenden overbodige testruns per week zijn niet gratis, ook niet voor het klimaat.
  • Onderhoud: elke test die je toevoegt, is een test die iemand moet begrijpen en bijwerken.

Van coverage-doel naar teststrategie

Het alternatief is niet minder testen, maar gerichter testen. Voordat ik aan een feature of bugfix begin, breng ik in kaart wat ik wil testen en op welk niveau. Niet elke functie leent zich voor een unit test, en dat is prima:

  • Unit tests voor pure logica: berekeningen, validaties, transformaties. Snel, stabiel en goedkoop.
  • Screenshot- of golden tests voor visuele componenten. In Flutter zijn golden tests hiervoor een uitstekend voorbeeld: je legt de gewenste rendering vast en elke ongewenste visuele wijziging valt direct op. Een unit test op een UI-component zegt vaak weinig, terwijl een golden test laat zien wat de gebruiker daadwerkelijk te zien krijgt.
  • Integratietests waar componenten en services samenkomen: API-routes, database-interacties en third-party-koppelingen.
  • E2E-tests voor de kritieke gebruikersflows: inloggen, afrekenen, formulieren versturen. Weinig in aantal, hoog in waarde.
  • Synthetische tests in productie, die periodiek de belangrijkste flows doorlopen en alarm slaan voordat gebruikers dat doen.

Met zo'n strategie hoef je je coverage niet op 100% te pinnen. Een bewuste keuze om een stuk code níet te unit-testen omdat het al gedekt wordt door een integratietest of golden test, is waardevoller dan een test die alleen bestaat om een percentage te halen.

AI verlaagt de drempel voor de hele strategie

Voorheen was er vaak een technische drempel om integratietests of screenshot tests op te zetten: tooling configureren, test-infrastructuur inrichten, fixtures bouwen. Voor veel teams was dat de reden om het bij unit tests te laten. Niet omdat dat de beste keuze was, maar omdat het de laagste instap had.

Die drempel is grotendeels verdwenen. Met een paar gerichte prompts zet een agentic AI een Playwright-setup neer, configureert screenshot-vergelijkingen of bouwt een synthetische monitoring-check. Wat vroeger dagen kostte aan uitzoekwerk, is nu in een middag operationeel. De afweging is daarmee niet langer wat je technisch aankunt, maar wat je wilt testen en waarom. En dat is precies de vraag die je als team zou moeten stellen.

Hoe ik dit in de praktijk aanpak

Bij elke feature of bugfix begin ik met een korte testafweging: welk gedrag moet gegarandeerd blijven, op welk niveau test ik dat het goedkoopst, en welke bestaande tests dekken dit al? Die afweging leg ik vast in de PR-beschrijving. De AI helpt vervolgens bij het implementeren, maar de strategie blijft mensenwerk. AI is uitstekend in het schrijven van tests. Bepalen welke tests er moeten zijn, vraagt om begrip van het product, de risico's en de gebruikers.

Conclusie

AI gebruiken om tests te schrijven is relevanter dan ooit, juist omdat het je in staat stelt om verder te kijken dan unit tests alleen. Coverage-thresholds hebben nog steeds een functie als signaal, maar als hard doel werken ze averechts in een AI-workflow. Investeer die energie liever in een expliciete teststrategie per wijziging. Je pipeline blijft snel, je tests blijven betekenisvol en je team weet precies waarom elke test bestaat.