Software testen dat je zelf niet hebt ontworpen, betekent dat je het mentale model mist dat de auteur gebruikte. Bij AI-gegenereerde code was er geen menselijke auteur, dus dat model bestaat mogelijk helemaal niet. Het praktische gevolg is dat coveragestatistieken onbetrouwbare maatstaven voor vertrouwen worden.
Waarom coverage hier misleidend is
Regel- en branchcoverage vertellen je welke code tijdens tests is uitgevoerd. Ze zeggen niets over of de tests zijn geschreven om het juiste gedrag te onderzoeken. Wanneer een model zowel de implementatie als de testset genereert, weerspiegelen de tests de aannames die de code hebben gevormd. Hiaten in het begrip van het model verschijnen op beide plaatsen tegelijk, waardoor coveragecijfers er gezond uitzien terwijl betekenisvolle scenario's ongetest blijven.
Dit is geen theoretisch risico. AI-modellen genereren plausibel ogende code. Plausibel en correct zijn niet hetzelfde, en een test die is geschreven door hetzelfde model dat de functie schreef, zal zelden het verschil aan het licht brengen.
Wat je in plaats daarvan doet
De verschuiving gaat van het meten van uitvoering naar redeneren over gedrag.
Begin met de specificatie, niet met de code. Schrijf tests op basis van vereisten of verwacht gedrag voordat je de implementatie leest. Als er geen specificatie bestaat, schrijf er dan een, al is het maar kort, voordat je het gegenereerde bestand opent. Dit voorkomt dat de code je verwachtingen stuurt.
Test de grenzen die het model waarschijnlijk niet heeft overwogen. Modellen gaan doorgaans goed om met het happy path. Edge cases met lege invoer, gelijktijdige schrijfacties, locale-verschillen, integer overflow of ontbrekende rechten zijn vaker onderbelicht. Benoem deze onafhankelijk.
Gebruik property-based testing waar praktisch. In plaats van specifieke uitvoer te controleren, controleer je invarianten: een sorteerfunctie moet altijd een lijst van dezelfde lengte teruggeven; een prijsfunctie mag nooit een negatieve waarde teruggeven. Property-based tools genereren automatisch honderden invoerwaarden en brengen aannames aan het licht die het model stilzwijgend heeft ingebakken.
Lees de code op intentie, niet alleen op correctheid. Voordat je de testset vertrouwt, loop je door de implementatie en vraag je je af waarvoor de code is geoptimaliseerd. AI-gegenereerde code lost soms een iets ander probleem op dan het opgegeven probleem, met name wanneer de prompt dubbelzinnig was. Het begrijpen van het werkelijke gedrag, in plaats van het beoogde gedrag, verandert wat je test.
Behandel externe aanroepen met extra scepsis. Gegenereerde code die API's, databases of queues aanroept, mockt die afhankelijkheden in tests vaak weg. Controleer of de mocks weerspiegelen hoe de echte afhankelijkheid zich daadwerkelijk gedraagt, inclusief foutmodi en rate limits, en niet alleen het succesgeval.
De vertrouwensvraag
Coverage is een maatstaf voor vertrouwen omdat, bij code die een mens heeft geschreven, degene die het schreef doorgaans ook de tests heeft ontworpen om de dingen te ondervangen waar diegene zich zorgen over maakte. Die relatie valt weg wanneer de code en tests een gemeenschappelijke geautomatiseerde oorsprong delen.
Vertrouwen in AI-gegenereerde code moet ergens anders vandaan komen: van begrip van wat de code doet, van tests geschreven op basis van de specificatie in plaats van de implementatie, en van systematische aandacht voor de categorieën fouten die modellen structureel onderwaarderen.
Dit hangt samen met de bredere vraag hoe je AI-gegenereerde code reviewt. Code review en testen zijn verschillende activiteiten. Als er geen menselijke ontwerper achter de code zit, moeten ze elkaar meer aanvullen dan normaal. Een engineer die alleen een linter kan draaien en de coverage kan checken, is hier niet voor toegerust.
Het sluit ook aan op wat er is veranderd aan code review in bredere zin. De reviewende engineer is nu de voornaamste bron van ontwerpinzicht, niet alleen iemand die andermans werk goedkeurt.
Waar we op testen
Drie van onze scorecardcriteria zijn hier direct op van toepassing. AI output verificatie beoordeelt of een engineer gehallusineerde API's, subtiel foutieve logica of beveiligingsfouten onderschept voordat gegenereerde code live gaat. Risicogericht oordelen kijkt of de reviewinspanning schaalt met de consequenties, niet met de mate van vertrouwen van de agent. Eigenaarschap omvat tests, observability en debuggen na release, ongeacht wie de code heeft geschreven. Beide sessies testen dit onder realistische omstandigheden, met en zonder AI-tools. Zie hoe we vetten.
Korte antwoorden
Waarom is 100% coverage niet voldoende voor AI-gegenereerde code?
Coverage meet welke regels zijn uitgevoerd, niet of de juiste vragen zijn gesteld. Wanneer hetzelfde model de code en de tests schrijft, delen beide dezelfde blinde vlekken. Hoge coverage kan samengaan met grote ongeteste categorieën gedrag.
Schrijf je tests voor of na het lezen van AI-gegenereerde code?
Voor, waar mogelijk. De implementatie eerst lezen verankert je verwachtingen aan wat het model heeft geproduceerd. Tests eerst schrijven op basis van de specificatie dwingt je om correct gedrag onafhankelijk te definiëren, wat discrepanties betrouwbaarder aan het licht brengt.
Welke soorten fouten missen AI-gegenereerde tests het vaakst?
Edge cases met lege of misvormde invoer, gelijktijdige toegang, fouten in externe afhankelijkheden, locale- of tijdzonegevoeligheid, en permissiegrenzen. Modellen optimaliseren voor het happy path; systematisch testen moet de gevallen bestrijken die onwaarschijnlijk maar consequential zijn.
