Vad är testdriven utveckling (TDD)? Exempel

Vad är testdriven utveckling (TDD)?

Testdriven utveckling (TDD) är ett tillvägagångssätt för mjukvaruutveckling där testfall utvecklas för att specificera och validera vad koden kommer att göra. Enkelt uttryckt skapas och testas testfall för varje funktionalitet först och om testet misslyckas skrivs den nya koden för att klara testet och göra koden enkel och buggfri.

Testdriven utveckling börjar med att designa och utveckla tester för varje liten funktionalitet i en applikation. TDD-ramverket instruerar utvecklare att skriva ny kod endast om ett automatiserat test har misslyckats. Detta undviker duplicering av kod. TDD full form är testdriven utveckling.

Det enkla konceptet med TDD är att skriva och korrigera de misslyckade testerna innan du skriver ny kod (före utveckling). Detta hjälper till att undvika duplicering av kod eftersom vi skriver en liten mängd kod åt gången för att klara tester. (Tester är inget annat än kravvillkor som vi måste testa för att uppfylla dem).

Testdriven utveckling är en process för att utveckla och köra automatiserade tester före faktisk utveckling av applikationen. Därför kallas TDD ibland också som Testa första utvecklingen.

Hur man utför TDD-test

Följande steg definierar hur man utför TDD-test,

Lägg till ett test.
Kör alla tester och se om något nytt test misslyckas.
Skriv lite kod.
Kör tester och Refactor-kod.
Upprepa.

TDD-cykeln definierar

Skriv ett test
Få det att köra.
Ändra koden så att den blir rätt, dvs. Refactor.
Upprepa processen.

Några förtydliganden om TDD:

TDD-metoden handlar varken om "testning" eller om "design".
TDD betyder inte "skriv några av testerna och bygg sedan ett system som klarar testerna.
TDD betyder inte "gör massor av tester."

TDD vs. Traditionell testning

Nedan är huvudskillnaden mellan testdriven utveckling och traditionell testning:

TDD-metoden är i första hand en specifikationsteknik. Det säkerställer att din källkod testas noggrant på bekräftande nivå.

Med traditionell testning hittar ett lyckat test en eller flera defekter. Det är samma som TDD. När ett test misslyckas har du gjort framsteg eftersom du vet att du måste lösa problemet.
TDD säkerställer att ditt system faktiskt uppfyller krav som definierats för det. Det hjälper till att bygga upp ditt förtroende för ditt system.
I TDD ligger mer fokus på produktionskod som verifierar om testning kommer att fungera korrekt. I traditionell testning ligger mer fokus på testfallsdesign. Huruvida testet kommer att visa korrekt/felaktigt utförande av applikationen för att uppfylla kraven.
I TDD uppnår du 100% täckningstest. Varje enskild kodrad testas, till skillnad från traditionella tester.
Kombinationen av både traditionell testning och TDD leder till vikten av att testa systemet snarare än perfektion av systemet.
In Agile Modeling (AM), bör du "testa med ett syfte". Du bör veta varför du testar något och vilken nivå det behöver testas.

Vad är acceptans TDD och utvecklare TDD

Det finns två nivåer av TDD

Acceptans TDD (ATDD): Med ATDD skriver du ett enda acceptanstest. Detta test uppfyller kravet i specifikationen eller tillfredsställer systemets beteende. Skriv efter det precis tillräckligt med produktions-/funktionskod för att uppfylla acceptanstestet. Acceptanstestet fokuserar på systemets övergripande beteende. ATDD var också känd som Beteendedriven utveckling (BDD).
Utvecklare TDD: Med Developer TDD skriver du enstaka utvecklartest dvs enhetstest och sedan precis tillräckligt med produktionskod för att klara det testet. Enhetstestet fokuserar på varje liten funktionalitet i systemet. Utvecklare TDD kallas helt enkelt som TDD.Huvudmålet med ATDD och TDD är att specificera detaljerade, körbara krav för din lösning på just in time-basis (JIT). JIT innebär att man endast tar hänsyn till de krav som behövs i systemet. Så öka effektiviteten.

Skala TDD via Agil Model Driven Development (AMDD)

TDD är mycket bra på detaljerade specifikationer och validering. Det misslyckas med att tänka igenom större frågor som övergripande design, användning av systemet eller användargränssnitt. AMDD tar itu med Agile-skalningsproblemen som TDD inte gör.

Således AMDD används för större frågor.

AMDD:s livscykel

I Model-driven Development (MDD) skapas omfattande modeller innan källkoden skrivs. Som i sin tur har ett agilt förhållningssätt?

I ovanstående figur representerar varje ruta en utvecklingsaktivitet.

Envisioning är en av TDD-processerna för att förutsäga/föreställa tester som kommer att utföras under den första veckan av projektet. Huvudmålet med föreställningen är att identifiera systemets omfattning och systemets arkitektur. Högnivåkrav och arkitekturmodellering görs för framgångsrik föreställning.

Det är processen där inte en detaljerad specifikation av programvara/system görs utan utforskar kraven på programvara/system som definierar projektets övergripande strategi.

Iteration 0: Envisioning

Det finns två huvudsakliga underaktiveringar.

Initiala krav föreställa sig.Det kan ta flera dagar att identifiera krav på hög nivå och systemets omfattning. Huvudfokus är att utforska användningsmodell, initial domänmodell och användargränssnittsmodell (UI).
Initial Architeknisk föreställning. Det tar också flera dagar att identifiera systemets arkitektur. Det gör det möjligt att ange tekniska anvisningar för projektet. Huvudfokus är att utforska teknikdiagram, användargränssnitt (UI) flöde, domänmodeller och förändringsfall.

Iterationsmodellering

Här måste teamet planera arbetet som ska göras för varje iteration.

Agil process används för varje iteration, dvs under varje iteration kommer ett nytt arbetsobjekt att läggas till med prioritet.
Det första högre prioriterade arbetet kommer att beaktas. Arbetsobjekt som läggs till kan omprioriteras eller tas bort från objektstapeln när som helst.
Teamet diskuterar hur de ska implementera varje krav. Modellering används för detta ändamål.
Modelleringsanalys och design görs för varje krav som kommer att implementeras för den iterationen.

Modell stormar

Detta är också känt som Just in time Modeling.

Här involverar modelleringssessionen ett team på 2/3 medlemmar som diskuterar frågor på papper eller whiteboard.
En gruppmedlem kommer att be en annan att modellera med dem. Denna modelleringssession kommer att ta cirka 5 till 10 minuter. Där teammedlemmar samlas för att dela whiteboard/papper.
De utforskar problem tills de inte hittar huvudorsaken till problemet. Precis i tid, om en gruppmedlem identifierar problemet som han/hon vill lösa kommer han/hon att ta snabb hjälp av andra teammedlemmar.
Andra gruppmedlemmar utforskar sedan frågan och sedan fortsätter alla som tidigare. Det kallas också som stand-up modellering eller kund QA sessioner.

Testdriven utveckling (TDD)

Det främjar bekräftande testning av din applikationskod och detaljerade specifikationer.
Både acceptanstest (detaljerade krav) och utvecklartest (enhetstest) är indata för TDD.
TDD gör koden enklare och tydlig. Det gör att utvecklaren kan underhålla mindre dokumentation.

Omdömen

Detta är valfritt. Det inkluderar kodinspektioner och modellgranskningar.
Detta kan göras för varje iteration eller för hela projektet.
Detta är ett bra alternativ för att ge feedback för projektet.

Testdriven utveckling (TDD) vs. Agil modelldriven utveckling (AMDD)

TDD	AMDD
TDD förkortar programmeringsåterkopplingsslingan	AMDD förkortar modelleringsfeedbackslingan.
TDD är detaljerad specifikation	AMDD fungerar för större problem
TDD främjar utvecklingen av högkvalitativ kod	AMDD främjar högkvalitativ kommunikation med intressenter och utvecklare.
TDD talar till programmerare	AMDD pratar med Affärsanalytiker, intressenter och dataproffs.
TDD icke-visuellt orienterad	AMDD visuellt orienterad
TDD har begränsad räckvidd till mjukvaruarbeten	AMDD har en bred räckvidd inklusive intressenter. Det handlar om att arbeta mot en gemensam förståelse
Båda stöder evolutionär utveckling	---------------

TDD-ramverk

Här är listan över de bästa ramverken för testdriven utveckling (TDD).

junit
TestNG
csUnit och NUnit
Rspec

Låt oss nu lära oss Testdriven utveckling genom exempel.

Exempel på TDD

Här i detta testdrivna utvecklingsexempel kommer vi att definiera ett klasslösenord. För denna klass kommer vi att försöka uppfylla följande villkor.

Ett villkor för lösenordsacceptans:

Lösenordet ska vara mellan 5 och 10 tecken.

Först i detta TDD-exempel skriver vi koden som uppfyller alla ovanstående krav.

Scenario 1: För att köra testet skapar vi klassen PasswordValidator ();

Vi kommer att köra ovanför klass TestPassword ();

Utgången är PASSAD som visas nedan;

Produktion:

Scenario 2: Här kan vi se i metoden TestPasswordLength () att det inte finns något behov av att skapa en instans av klassen PasswordValidator. Instans betyder att skapa en objektet av klassen för att hänvisa medlemmarna (variabler/metoder) i den klassen.

Vi kommer att ta bort klassen PasswordValidator pv = new PasswordValidator () från koden. Vi kan ringa är giltig () metod direkt av Password Validator. IsValid ("Abc123"). (Se bild nedan)

Så vi Refactor (ändra kod) enligt nedan:

Scenario 3: Efter omfaktorisering visar utdata statusen misslyckad (se bilden nedan) detta beror på att vi har tagit bort instansen. Så det finns ingen hänvisning till icke-statisk metod är giltig ().

Så vi måste ändra den här metoden genom att lägga till "statiskt" ord före Boolean som public static boolean isValid (stränglösenord). Refactoring Class PasswordValidator () för att ta bort ovanstående fel för att klara testet.

Produktion:

Efter att ha gjort ändringar i klassen PassValidator () om vi kör testet kommer utgången att godkännas som visas nedan.

Fördelar med TDD

Följande är de viktigaste fördelarna med testdriven utveckling inom mjukvaruteknik:

Tidig felmeddelande.

Utvecklare testar sin kod men i databasvärlden består detta ofta av manuella tester eller engångsskript. Med hjälp av TDD bygger du över tiden upp en serie automatiserade tester som du och vilken annan utvecklare som helst kan köra om efter behag.

Bättre designad, renare och mer utbyggbar kod.

Det hjälper till att förstå hur koden kommer att användas och hur den interagerar med andra moduler.
Det resulterar i bättre designbeslut och mer underhållbar kod.
TDD tillåter att skriva mindre kod med ett enda ansvar snarare än monolitiska procedurer med flera ansvarsområden. Detta gör koden enklare att förstå.
TDD tvingar också att bara skriva produktionskod för att klara tester baserat på användarkrav.

Förtroende till Refactor

Om du refaktorerar kod kan det finnas möjligheter till brott i koden. Så med en uppsättning automatiska tester kan du åtgärda dessa avbrott före release. Korrekt varning kommer att ges om avbrott hittas när automatiserade tester används.
Att använda TDD bör resultera i snabbare, mer utbyggbar kod med färre buggar som kan uppdateras med minimala risker.

Bra för lagarbete

I frånvaro av någon gruppmedlem kan andra teammedlemmar enkelt hämta och arbeta med koden. Det underlättar också kunskapsdelning, vilket gör teamet mer effektivt totalt sett.

Bra för utvecklare

Även om utvecklare måste lägga mer tid på att skriva TDD-testfall, tar det mycket mindre tid för att felsöka och utveckla nya funktioner. Du kommer att skriva renare, mindre komplicerad kod.

Sammanfattning

TDD står för Testdriven Development.
TDD betyder: Det är en process för att modifiera koden för att klara ett tidigare designat test.
Den lägger mer vikt på produktionskod snarare än testfallsdesign.
Testdriven utveckling är en process för att modifiera koden för att klara ett tidigare designat test.
In Mjukvaruutveckling, Det kallas ibland "Testa första utvecklingen."
TDD-testning inkluderar omfaktorering av en kod, dvs. ändra/lägga till en viss mängd kod till den befintliga koden utan att påverka kodens beteende.
TDD-programmering när den används blir koden tydligare och enklare att förstå.

Du kanske gillar: