AI-genererad kod behöver mer test, inte mindre. Inte för att den är sämre, utan för att ingen människa har resonerat sig fram till den. Testet är det enda som säger att koden gör rätt sak i ditt system — och det är också den uppgift modellen är allra bäst på att hjälpa till med.
Varför testbehovet ökar
När du skriver kod själv testar du den delvis medan du skriver. Du tänker igenom gränsfallen för att kunna skriva raden. Den mentala genomgången är osynlig men den är verklig kvalitetssäkring.
När koden genereras uteblir det steget. Du får ett färdigt resultat utan att ha vandrat igenom logiken. Koden kan vara bättre än den du själv skulle skrivit — men du har inte den förståelse du brukar ha när du trycker på merge.
Testet är det som återställer balansen. Det är dessutom det billigaste stället att lägga tiden, eftersom det är precis den sortens uppgift modellen är stark på: tydligt mönster, snabbt att verifiera.
Testet som skrivs först
Det finns ett arbetssätt som fungerar påfallande bra ihop med AI, och som är enklare än det låter: skriv testet innan du ber om implementationen.
Inte som ideologi, utan för att det löser ett konkret problem. Ett test skrivet i förväg är en exakt specifikation av vad du vill ha — mycket mer precis än en prompt i löptext. Och det ger dig ett utfall att verifiera mot som inte kommer från samma källa som koden.
Be aldrig om testet och implementationen i samma prompt. Då skriver modellen ett test som passar den kod den tänkte skriva, och du har byggt ett slutet system som bekräftar sig självt. Det ser ut som täckning och är i praktiken en tautologi.
Vad modellen är bra på att testa
Styrkan ligger i uttömmande men tråkigt arbete — precis det människor hoppar över när det är sent på fredagen.
Be om det här
- Gränsfall du inte tänkt på. "Vilka indata skulle kunna få den här funktionen att bete sig oväntat?" är en av de mest lönsamma frågor du kan ställa.
- Tabelldrivna tester. Femton varianter av samma anrop med olika indata, snyggt uppställda. Enformigt att skriva, snabbt att generera.
- Testdata som liknar verkligheten. Namn med å, ä och ö, adresser med olika format, datum kring årsskiften och sommartid.
- Tester för befintlig kod. Du vet vad funktionen ska göra, koden finns, testet går att köra direkt — de tre villkor som gör uppgiften idealisk.
Genererade tester som inte testar något
Det finns ett återkommande mönster värt att känna igen: testet ser komplett ut, går igenom, och skulle fortsätta gå igenom även om koden var trasig.
assert result != null och liknande. Sant nästan alltid, informativt nästan aldrig.Ett snabbt sätt att kontrollera: ändra implementationen så att den blir fel, med flit. Om inget test faller vet du att täckningen är kosmetisk. Det tar en minut och är den enda kontrollen som faktiskt mäter något.
I den fristående artikeln om att mutationstesta AI-genererade tester blir kontrollen ett reproducerbart arbetsflöde: välj en meningsfull mutant, kör den separat, triagera överlevare och stoppa nya testluckor i CI.
När testobjektet är ett AI-anrop behöver du dessutom skilja varierande indata från varierande svar. Artikeln om reproducerbarhetstest för AI-anrop visar hur en kanonisk request, två output-hashar och upprepade körningar lokaliserar skillnaden utan att anta att en seed låser formuleringen.
Ett besläktat prov behöver inte anropa modellen alls. Artikeln om att validera modellens strukturerade svar matar integrationen med fastlagda, medvetet felaktiga svar — påhittade enum-värden, tysta typbyten, uppdiktade id:n — och kontrollerar att ingen biverkan sker. Det är deterministiskt, gratis och kan köras vid varje ändring.
En egen felklass är kod som svarar rätt men betalar för mycket för det. Artikeln om N+1-frågorna som AI-koden skriver in visar de tre former mönstret tar i en diff och hur du gör antalet databasfrågor till ett värde testet hävdar, i stället för en osynlig egenskap som bara märks under last.
Ett annat grönt happy-path-test kan dölja ett trasigt bestående tillstånd. Artikeln om transaktionen som AI-koden glömmer placerar ett avsiktligt fel mellan flera beroende databasskrivningar och kontrollerar sedan att ordern saknas, lagret är oförändrat och ingen händelse ligger kvar. Det gör allt-eller-inget-egenskapen till ett testresultat i stället för ett antagande om ramverket.
Täckning som ljuger
Kodtäckning mäter vilka rader som kördes, inte om något kontrollerades. Ett testsvit som anropar all kod och inte påstår något om resultatet ger utmärkt täckning och noll trygghet.
Det blir extra vilseledande med genererade tester, eftersom de är snabba att producera i mängd. Nittio procents täckning som uppstått på tio minuter betyder något annat än nittio procent som vuxit fram under ett halvår.
Använd täckning för att hitta det som är helt otestat — där är den användbar. Använd den inte som mått på kvalitet.
En praktisk miniminivå
Om det ska vara en enda regel: testa huvudflödet och felvägarna för allt som rör användarkonton, pengar eller data som inte går att återskapa. Resten kan vara pragmatiskt.
För ett större kodarbete finns en djupare, engelskspråkig fortsättning i mallen för en AI-regressionstestplan, med riskinventering, testmatris och stoppregler före merge.
Tester säger att koden gör rätt. Nästa guide handlar om en fråga tester inte svarar på: vad som får lämna huset.