Att testa programvara som du inte har designat innebär att du saknar den mentala modell som upphovsmannen använde. Med AI-genererad kod fanns det ingen mänsklig upphovsman, så den modellen kanske inte existerar alls. Den praktiska konsekvensen är att täckningsmått blir opålitliga som indikatorer på tillförlitlighet.
Varför täckning vilseleder här
Rad- och grentäckning talar om vilken kod som kördes under testerna. De säger ingenting om huruvida testerna skrevs för att undersöka rätt beteende. När en modell genererar både implementationen och testsviten tenderar testerna att återspegla samma antaganden som formade koden. Luckor i modellens förståelse uppträder på båda ställena samtidigt, så täckningssiffrorna ser bra ut medan meningsfulla scenarier förblir otestade.
Det här är ingen teoretisk risk. AI-modeller genererar kod som ser rimlig ut. Rimlig och korrekt är inte samma sak, och ett test skrivet av samma modell som skrev funktionen kommer sällan att avslöja skillnaden.
Vad du bör göra i stället
Skiftet går från att mäta exekvering till att resonera om beteende.
Börja med specifikationen, inte koden. Skriv tester utifrån krav eller förväntat beteende innan du läser implementationen. Om ingen specifikation finns, skriv en, om så bara kortfattat, innan du öppnar den genererade filen. Det förhindrar att koden styr dina förväntningar.
Testa de gränsvärden som modellen sannolikt inte beaktade. Modeller hanterar ofta den lyckliga vägen väl. Kantfall med tomma indata, parallella skrivningar, lokala skillnader, heltalsöverflöde eller saknade behörigheter är mer sannolikt svagt täckta. Räkna upp dessa oberoende av varandra.
Använd egenschaftsbaserad testning där det är praktiskt möjligt. I stället för att hävda specifika utdata, hävda invarianter: en sorteringsfunktion bör alltid returnera en lista med samma längd; en prissättningsfunktion bör aldrig returnera ett negativt värde. Egenschaftsbaserade verktyg genererar hundratals indata automatiskt och synliggör antaganden som modellen bakat in i tysthet.
Läs koden för att förstå avsikten, inte bara korrektheten. Innan du litar på testsviten, spåra igenom implementationen och fråga dig vad koden är optimerad för. AI-genererad kod löser ibland ett något annat problem än det som angavs, särskilt när prompten var tvetydig. Att förstå det faktiska beteendet, snarare än det avsedda beteendet, förändrar vad du testar.
Behandla externa anrop med extra skepticism. Genererad kod som anropar API:er, databaser eller köer mockar ofta dessa beroenden i tester. Kontrollera om mockarna återspeglar hur det faktiska beroendet beter sig i praktiken, inklusive fellägen och hastighetsbegränsningar, inte bara framgångsfallet.
Frågan om tillförlitlighet
Täckning är ett mått på tillförlitlighet eftersom, i kod som en människa har skrivit, den som skriver koden vanligtvis också utformar testerna för att fånga det de var oroliga för. Det sambandet bryts när koden och testerna delar ett enda automatiserat ursprung.
Tillförlitlighet i AI-genererad kod måste komma någon annanstans ifrån: från att förstå vad koden gör, från tester skrivna mot specifikationen snarare än implementationen, och från systematisk uppmärksamhet på de kategorier av fel som modeller konsekvent undervärderar.
Det här hänger ihop med den bredare frågan om hur du granskar AI-genererad kod. Kodgranskning och testning är olika arbetsmoment, men när koden saknar mänsklig upphovsperson måste de väga upp varandra mer än vanligt. En utvecklare som bara kan köra en linter och kontrollera täckningen är inte rustad för det.
Det hänger också ihop med vad som förändrades i kodgranskning mer generellt. Den granskande utvecklaren är nu den primära källan till designbedömning, inte bara en godkännare av någon annans arbete.
Vad vi testar
Tre av våra bedömningskriterier är direkt relevanta här. Verifiering av AI-resultat bedömer om en utvecklare fångar upp hallucinerade API:er, subtilt felaktig logik eller säkerhetsbrister innan genererad kod levereras. Riskbaserat omdöme undersöker om granskningsinsatsen skalas efter konsekvens, inte efter hur säker agenten lät. Ägandeskap täcker tester, observerbarhet och felsökning efter lansering, oavsett vem som skrivit koden. Båda sessionerna testar detta under realistiska förhållanden, med och utan AI-verktyg. Se hur vi granskar.
Korta svar
Varför räcker inte 100% täckning för AI-genererad kod?
Täckning mäter vilka rader som kördes, inte om rätt frågor ställdes. När samma modell skriver koden och testerna delar båda samma blinda fläckar. Hög täckning kan samexistera med stora otestade kategorier av beteende.
Bör du skriva tester före eller efter att du har läst AI-genererad kod?
Före, där det är möjligt. Att läsa implementationen först styr dina förväntningar mot vad modellen producerade. Att skriva tester från specifikationen först tvingar dig att definiera korrekt beteende oberoende, vilket synliggör avvikelser mer tillförlitligt.
Vilka typer av fel missar AI-genererade tester oftast?
Kantfall med tomma eller felaktigt formaterade indata, parallell åtkomst, fel i externa beroenden, lokaliserings- eller tidszonsberoende, och behörighetsgränser. Modeller optimerar för den lyckliga vägen; systematisk testning behöver täcka fall som är osannolika men konsekvensrika.
