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.
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.
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.