När du använder AI för att generera kod riskerar du att få logik som ser korrekt ut men som brister i kantfallen (edge cases). Genom att be AI-assistenten skriva tester i ett separat steg innan kodningen börjar, etablerar du ett kontrakt. Detta Test-Driven Development (TDD)-flöde tvingar fram robusthet och ger dig en automatiserad verifieringsmekanism för framtida refaktoreringar.
Varför AI älskar att fuska
Språkmodeller är experter på att producera text som ser övertygande ut. Om du ber den bygga en inloggningsfunktion kommer den glatt att spotta ur sig 200 rader kod. Men om du glömde nämna hur databasfel ska hanteras, kommer modellen ofta att lämna det fallet ohanterat eller lägga in en slapp console.log().
När du däremot tvingar fram en TDD-process sätter du stopp för dessa genvägar. Genom att tvinga modellen att specificera vad koden ska göra under olika förhållanden, innan den ens får skriva hur den gör det, definieras kantfallen strukturerat.
Ett säkrare promptflöde
Lösningen är inte att be om "kod med tester". Om du gör det kommer AI:n ofta att skriva koden först, och sedan skapa ytliga tester som bara verifierar "the happy path". Du måste stanna bandet mellan stegen.
Prompten för att skapa kontraktet
Agera som Senior Test Engineer.
Vi ska implementera [Beskriv funktionen, t.ex. lösenordsåterställning].
Din uppgift är ENBART att skriva enhetstester för detta i [Ditt testramverk, t.ex. Vitest]. Du får INTE skriva själva koden. Testerna ska agera som ett strikt kontrakt för vår kommande implementation.
Täck in följande scenarier:
- Normal och korrekt användning.
- Felaktig eller skadlig indata.
- Beroenden som kastar timeouts eller fel.
Returnera endast testkoden.
Regressionstester som skyddsnät
Den absolut största fördelen med att tvinga AI:n att skriva tester är vad som händer nästa vecka, när du ber den lägga till en ny funktion i samma fil. LLM:er är ökända för att råka skriva över eller ta bort gammal logik när de genererar stora textblock (s.k. regression). Om du har ett TDD-flöde på plats kör du bara din testsvit efter varje prompt. Om ett test går sönder vet du direkt att modellen har amputerat en gammal funktion.
Samma kontraktstanke fungerar utanför din egen kodbas. När det är ett externt API eller en modelluppdatering som kan ändra beteendet räcker inte enhetstester — då behöver du kontraktstester som fångar förändringen innan modellen uppdateras. Och när du väl vill bygga om koden bakom en passerande testsvit är poängen just att refaktorera utan att ändra beteendet: testerna är facit på att du lyckades.
Två primärkällor lästa 9 september 2026. De stödjer det artikeln förutsätter om testramverken: hur ett test skrivs och körs i de två som nämns. Promptflödet, kontraktet och regressionsnätet är artikelns egen metod. [1] Vitest: guide — uppsättning och körning av testerna i exemplen. [2] Jest: getting started — motsvarande för det äldre ramverket. Nästa kontroll senast 9 december 2026, eller tidigare om ett av ramverken ändrar sitt sätt att deklarera tester. Metoden i artikeln är ramverksoberoende; det är exemplen som binder den till ett verktyg.