Vad är testdriven utveckling? Eller TDD?

Vad är testdriven utveckling? Eller TDD?

Test Driven Development eller TDD som det är känt i utvecklarkretsarna är en viktig aspekt av mjukvaruutvecklingsprocessen. Genom detta tillvägagångssätt är det lättare att testa vad en specifik kod skulle utföra. Testfall för varje funktionalitet i programvaran skapas, och när en viss funktionalitet misslyckas i ett test skulle koden omarbetas och nya koder skapas. Den nya koden måste också klara testet och vara buggfri. Utvecklaren måste bara skriva en ny kod om det automatiska testet för koden har misslyckats, så det kommer att finnas ett testfall för varje funktionalitet, hur liten som helst. Och TDD handlar om att designa och utveckla tester för varje funktion i applikationen.

Namnet Test Driven Development indikerar att det är processen att göra tester på rätt sätt som driver mjukvaruutvecklingen. Därför härstammar själva processen från Agile metodik och extrem programmering. Denna process säkerställer att utvecklare skapar och underhåller kod som är motståndskraftig och långsiktig.

Så processen för TDD skulle vara att skriva enhetstestet först, och om testet misslyckas, implementera sedan kodändringarna. Detta hjälper också till att undvika dubblering av kod. Det hela går på att skriva och korrigera misslyckade tester innan själva utvecklingen. För att TDD ska fungera framgångsrikt är det dock lämpligt att skriva testfallen till enkla testfall. För komplex affärslogik skulle det vara riktigt svårt att skriva en kombination av testfall och uppnå full framgång. Det finns en chans att du kanske missar att skriva några tester, så det är inte en lätt uppgift alls.

Skillnad mellan TDD och traditionell testning

Traditionell testning är mer tidskrävande än TDD och baseras på upprepningen av en kort utvecklingscykel. Först skrivs testet från början, sedan skrivs programkoden, följt av systemets önskade beteende. När det skriftliga testet har godkänts (kontroll av att den oskrivna kodens arbete är korrekt) utförs refaktorering av den skrivna koden.

Inledningsvis kommer TDD också att vara tidskrävande, men med tiden kommer utvecklaren att vänja sig vid det eftersom utvecklingsprocessen kommer att bli mer strukturerad. Till exempel, när du anlitar en utvecklare kommer de att bestämma vad de ska skriva och sedan hur de ska skriva det.

Traditionell testning är framgångsrik när den korrekt hittar en eller flera defekter. Precis som TDD. Att hitta defekter är faktiskt ett bra tecken för då vet du att du måste lösa vad som är fel och gå vidare därifrån. TDD ger dig också mer självförtroende när du släpper programmet och ser till att det uppfyller de krav som det definieras för.

I traditionell testning är fokus mer på testfallets design, medan i TDD är fokus mer på produktionskod för att verifiera om testet fungerar enligt planen.

TDD ger dig 100% testtäckning, där testning görs för varje kodrad, det är inte fallet med traditionell testning.

När projektomfånget är riktigt stort måste du vara riktigt noggrann när du utför testerna. Och det finns en chans att testet kan bli försenat och passera budgeten och tidsbegränsningarna.

TDD kan vara svårt att skriva, och det kan bromsa utvecklingstiden, men det skulle definitivt löna sig i längden.

En annan nackdel med TDD är att konceptet är svårt att tillämpa på befintlig äldre kod.

Det är alltid bra att testet misslyckas innan du släpper ett projekt, för då vet du att du har kört ett giltigt test. Genom TDD vet du att ditt system uppfyller de krav som det är utformat för. Så fokus ligger mer på produktionskod för TDD, eftersom det säkerställer om testet kommer att fungera korrekt. Och när programvaran uppfyller alla krav som är avsedda för den.

De olika stadierna i en testdriven utveckling

Det finns tre olika stadier av TDD: Röd, grön och Refactor

Följ denna stegordning säkerställer att du har tester för koden du skriver, så du måste bara skriva koder för de tester du gör.

Den röda scenen

Tanken med det röda stadiet är att få testet att misslyckas, och den svåraste fasen också eftersom den utvecklas måste skriva test mot ingen kod. Nya utvecklare måste ha svårt eftersom de skulle vara förvirrade om vad de ska testa utan att ha koden för det. Men det är en vanlig sak och med erfarenhet kommer det att bli smidigt. Det första testet skrivs utan att skriva kod och för att deklarera klass och metod, och testet kommer att ha kompileringsfel. Nästa steg skulle vara att fixa kompileringsfelet och köra testet för att misslyckas. Detta orsakar den röda flaggan.

Den gröna fasen

Efter det röda steget skulle nästa steg vara att skriva koden. Denna kod måste klara det första testet. Att bara skriva tillräckligt med kod för att se till att bara det första testet klarar sig är ett hinder som många utvecklare står inför. För i nästa test måste det misslyckas, följt av ny kod för att skicka dem.

Refraktor -fasen

I de två första stadierna, där testet först måste misslyckas och sedan klara det, var målet att sedan få testerna att klara. Men i Refractor -fasen måste andra faktorer beaktas som kodkvalitet, kodunderhållbarhet, kodläsbarhet etc. Fokus här är alltså på dessa aspekter, så enhetstesterna kommer att fokusera på dessa. I ombyggnadsfasen behöver du inte oroa dig för saknad funktionalitetsaspekt, för när kodändringarna sker kommer testfallen automatiskt att överensstämma med funktionalitetsdelen också.

TDD passar väl in i Agile -metodiken

Det är helt uppenbart att projektkraven kan ändras långt in i utvecklingsstadiet, så att ha TDD i samarbete med Agile utveckling kommer definitivt att göra det framgångsrikt och bygga projekt som är anpassade till kundernas krav. Med testdriven utveckling får du en tidigare feedback på projektet som du enkelt kan arbeta med.

Det skulle också hjälpa till att förutse och minska de kritiska flaskhalsarna och säkerställa att projektet går vidare som avsett. Utvecklarteam kan spara mycket tid eftersom testerna skapas mycket tidigare i projektutvecklingen, och de behöver inte oroa sig för omfattande testskript.

Slutsats

Testdriven utveckling är en teknik som verkligen är tidskrävande, men den är värdefull i den meningen att den hjälper till att driva ditt projekt i rätt riktning genom att få korrekt feedback om projektet och upptäcka buggar. Det är dock ett mycket bättre alternativ än traditionella tester eftersom det kräver mer tid och pengar.

Intressanta länkar:

Testdriven utveckling: vad det är och vad det inte är.

Mer information om testdriven utveckling

Bilder: Canva

Författaren: Sascha Thattil arbetar på Software-Developer-India.com som är en del av YUHIRO Group. YUHIRO är ett tysk-indiskt företag som tillhandahåller programmerare till IT-företag, byråer och IT-avdelningar.