~/blog/tag/testing
Testen
De suite is het enige dat tussen een zelfverzekerde agent en productie in staat. Wat hij dan waard moet zijn.
Waar ik hier over schrijf
Genereren werd goedkoop, en daarmee veranderde de testsuite stilletjes van functie. Vroeger was hij een vangnet onder code waar al iemand over had nagedacht. Nu is hij vaak het enige dat überhaupt over die code heeft nagedacht.
Dat legt een gewicht op tests waar ze nooit voor ontworpen zijn, en het laat zien hoe weinig de meeste suites werkelijk vastleggen. Een suite die slaagt vertelt je dat de code is uitgevoerd. Coverage vertelt je dat een regel is langsgekomen. Geen van beide vertelt je dat er iets zou omvallen als het gedrag verandert, en dat is de enige vraag die telt zodra de auteur een model is dat met alle plezier een test schrijft die bevestigt wat de code toch al deed.
Mutation testing beantwoordt die vraag wel, en het is het instrument waar ik hier telkens op terugkom. Sloop expres iets, kijk of de suite het merkt. Het getal dat eruit komt ligt meestal lager dan mensen verwachten en zegt altijd meer dan coverage.
De andere stukken onder deze tag gaan over de problemen eromheen. Characterization tests, omdat je eerst moet vastleggen wat de code nu doet voordat je een agent aan legacy code laat werken. Baselines die vastleggen wat er al staat en weigeren wat er net bij kwam. Bevroren takensets, voor de vraag of een modelwissel je output slechter maakte, want de prompt nog een keer draaien geeft daar geen antwoord op.
Waarom dit allemaal telt staat in de gids over AI en codekwaliteit. De reeks over codekwaliteit zet de methodestukken in leesvolgorde.
beste startpunten
- AI genereert je tests. Maar test het ook echt?
De duidelijkste demonstratie van het probleem. Een agent schrijft de tests, ze slagen, en mutation testing laat zien hoeveel ervan het zouden merken als de code stukgaat.
- Legacy code refactoren met AI: begin met characterization tests
Waar tests ophouden hygiëne te zijn en een voorwaarde worden. Je kunt geen agent loslaten op code waarvan niemand het gedrag heeft vastgelegd.
- AI-codekwaliteit meten: het dashboard voorbij coverage en mutation testing
Waar je op let voorbij de mutation score, en de val in elk instrument waardoor een getal stijgt terwijl de codebase achteruitgaat.
Kwaliteitsdrempels voor AI-code: baselines die alleen strenger worden
Met een lint-baseline dwing je een standaard af die je codebase vandaag nog niet haalt. Bestaande overtredingen krijgen vrijstelling, nieuwe breken de build, en het bestand mag alleen krimpen. Hoe PHPStan, ESLint, detekt en Sonar dit doen, en de vier manieren waarop zo'n drempel stilletjes stopt met werken.
lees →Werd je code slechter na een modelwissel? AI-modellen vergelijken zonder benchmark
Je wisselt van model, er zit iets niet lekker, en je hebt niets om naar te wijzen. Waarom de prompt opnieuw draaien en een model als jury inzetten allebei niet werken, en de kleine, saaie meetopstelling die de vraag wel beantwoordt.
AI-codekwaliteit meten: het dashboard voorbij coverage en mutation testing
Coverage bewijst dat een regel draaide, mutation testing bewijst dat een test een bug zou vangen, maar geen van beide zegt iets over of de code stiekem lastiger wordt om aan te passen. Wat complexiteit, clone-detectie en fitness functions wel vangen.
Legacy code refactoren met AI: begin met characterization tests
Een coding agent is op zijn best in de code waar niemand aan wil komen, en juist daar ook op zijn gevaarlijkst. Zo refactor je legacy code met AI zonder het gedrag te slopen: eerst vastleggen wat de code doet, dan pas verplaatsen.
AI genereert je tests. Maar test het ook echt?
AI-tests halen in seconden een hoge coverage, maar coverage bewijst alleen dat een regel is uitgevoerd. Mutation testing bewijst dat de tests een bug ook echt vangen, en Chaos-MCP zet die loop in je agent.
Je vindt de bug niet als je de code niet schreef
AI maakt je geen slechtere programmeur. Het maakt je een slechtere lezer. Over debugging-instinct, vaardigheidsverlies, en waarom het grootste gat niet in het schrijven van code zit maar in het begrijpen ervan.
Waarom je nooit code moet shippen die je zelf niet snapt
Als je code niet aan een collega kunt uitleggen zonder te zeggen 'dat heeft de AI gedaan', dan hoort het niet in je repo. Over black boxes, WC-eend-tests en waarom hoop geen strategie is.