~/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 naast de mutation score op let, en de val in elk instrument waardoor een getal stijgt terwijl de codebase achteruitgaat.
Codekwaliteit bewaken bij AI-code: de hele opzet, van hook tot CI
De hele kwaliteitsopzet voor een project waarin een agent code schrijft: wat er in Claude Code-hooks, pre-commit, pre-push, CI en de wekelijkse mutation run hoort. En de eigenschap die elke controle nodig heeft, namelijk dat hij kan falen, met het bewijs uit drie van mijn eigen repository's.
leesDe upload kwam door de controle. De aanvaller ook.
Bricksforge controleerde of een upload een afbeelding was en liet daarna de browser bepalen waar de inhoud terechtkwam. De fout zat tussen twee stappen: een goede controle beschermde maar een deel van het proces.
Lege catch-blokken in AI-code: het commentaar dat je linter het zwijgen oplegt
AI-code slikt fouten in met catch-blokken waar alleen een commentaar in staat, en de aanbevolen ESLint-config laat ze juist dankzij dat commentaar door. Wat ik in mijn eigen repositories vond, waarom een model ze schrijft, en de regel die wel door het commentaar heen kijkt.
Wat een dependency-graph vindt dat je coding agent mist
Ik liet een scanner los op een interne applicatie waar agents al maanden in werkten. Hij deed er nog geen twee seconden over en leverde vier tickets op. Geen van die defecten zat in een bestand, en precies daarom vond niemand ze door bestanden te lezen.
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.
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.