Testdrevet utvikling med AI-agenter

Hva er TDD (Testdrevet utvikling)?

I sin kjerne dreier TDD seg om en syklisk prosess kjent som Red-Green-Refactor. Syklusen starter med “Red”-fasen, hvor en utvikler skriver en automatisert test som definerer en ønsket funksjon eller oppførsel. Denne testen er med vilje skrevet for å feile i starten fordi den tilhørende koden ikke eksisterer ennå. Denne første feilen er viktig fordi den bekrefter at testen faktisk tester den tiltenkte funksjonaliteten og kan fange feil når koden implementeres.

Den påfølgende “Green”-fasen innebærer å skrive et minimum av kode som er nødvendig for å få den tidligere feilede testen til å bestå. Dette prinsippet oppmuntrer utviklere til å fokusere på det umiddelbare kravet definert av testen, holde kodebasen ryddig og forhindre overengineering.

Til slutt fokuserer “Refactor”-fasen på å forbedre struktur, lesbarhet og vedlikeholdbarhet for både testkoden og produksjonskoden, samtidig som man sørger for at alle eksisterende tester fortsatt består. Refaktorisering sikrer at kodebasen forblir sunn og tilpasningsdyktig for fremtidige endringer uten å introdusere regresjoner, hvor testene fungerer som sikkerhetsnett.

Hvordan automatisere TDD-pipelinen din fullt ut?

Det er mange faktorer som påvirker ytelsen til AI-agenter under koding. Fra LLM-modellen til hvordan du strukturerer koden og utviklingsløpet ditt. Vi har erfart at TDD fungerer effektivt med Windsurf og Claude 3.5 sonnet. Her er et eksempel på en oppgave implementert med TDD.

Hva trenger du?

Før vi begynner å kode, trenger vi følgende:

Nok tester

Sørg for at du allerede har tester i tråd med TDD, og at de dekker mesteparten av problemet ditt som du mener er logisk og nyttig for AI-agenten. Du trenger ikke å endre eller tilpasse noe for AI-agentens skyld. Dersom testene dine og navngivningskonvensjonen følger en standard, er det en fordel. AI-agenten vil se disse testene først for å starte implementeringen.

Her er et eksempel på en test jeg har som sjekker om et dokument er riktig satt inn i MongoDB:

Grensesnitt

Et grensesnitt i Java (eller andre programmeringsspråk) er en struktur som definerer hvordan klasser skal se ut og hvilke metoder de skal implementere. For å veilede AI-agenten ytterligere, kan det være nyttig å lage et grensesnitt for ditt repository for innsetting av dokumenter:

Spesifikk beskrivelse av oppgaven

Til slutt trenger vi en spesifikk oppgavebeskrivelse. Vanligvis kan du bruke JIRA eller GitHub issues der du definerer oppgaven. Dette er vår:

Start Vibe Coding

Vibe coding betyr at du beskriver hva du ønsker på vanlig norsk (eller til og med stemmekommandoer), og AI genererer koden for deg i sanntid. Vi går i dybden på Vibe Coding i denne bloggen. Her er prompten jeg brukte i Windsurf for å løse oppgaven for meg:

Implementer følgende spørring som en kombinasjon av en eller flere navngitte spørringer og Java-kode.

Finn alle sjåfører som har fullført minst X turer med rating over 5 i et gitt datointervall, og som aldri har fått en rating under 3 stjerner.

Merk:
Du trenger ikke å finne én enkelt spørring for å løse denne oppgaven (du kan bruke en kombinasjon av Java-kode og navngitte spørringer), men du må ta hensyn til ORM-ytelse, altså sørge for at løsningen også er rimelig rask hvis du har mange entiteter. Under diskusjonssessionen bør du kunne forklare hvilke problemer som kan oppstå med dårlig skrevne spørringer.

@Ass1_2_2Test.java#L35-60 dette er de tilhørende testene. Den er implementert i @DriverDAO.java#L34-63

Å nevne filene er det viktigste når du driver med vibe coding. Nå kan du lene deg tilbake og se AI-agenten gjøre jobben sin. Den implementerte klassen, kjørte testene og itererte til testene bestod: