Vad är testdriven utveckling (TDD)? Självstudie med exempel

Testdriven utveckling börjar med att designa och utveckla tester för varje liten funktionalitet i en applikation. TDD instruerar utvecklare att skriva ny kod endast om ett automatiskt test misslyckades. Detta undviker duplicering av kod. Den fullständiga formen av TDD ä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 behöver testa för att uppfylla dem).

Testdriven utveckling är en process för att utveckla och köra automatiserad test innan den faktiska utvecklingen av applikationen. Därför kallas TDD ibland också som Test First Development.

I denna handledning lär du dig mer om-

• Hur man utför TDD-test
• TDD Vs. Traditionell testning
• Vad är acceptans TDD och utvecklare TDD
• Skalning TDD via Agile Model Driven Development (AMDD)
• Test Driven Development (TDD) Vs. Agile Model Driven Development (AMDD)
• Exempel på TDD
• Fördelar med TDD

Hur man utför TDD-test

Följande steg definierar hur TDD-test ska utföras,

1. Lägg till ett test.
2. Kör alla tester och se om något nytt test misslyckas.
3. Skriv några kod.
4. Kör tester och refaktorkod.
5. Upprepa.

TDD-cykeldefinierar

1. Skriv ett test
2. Gör det igång.
3. Ändra koden att göra det rätt, dvs Refactor.
4. Upprepa processen.

Några förtydliganden om TDD:

• TDD handlar inte heller om ”Testing” inte heller om ”Design”.
• TDD betyder inte ”skriv några av testerna, bygg sedan ett system som klarar testerna.
• TDD betyder inte” gör massor av tester. ”

TDD Vs. Traditionell testning

TDD-tillvägagångssätt är främst en specifikationsteknik. Det säkerställer att din källkod testas grundligt vid bekräftelse nivå.

• Med traditionell testning hittar ett framgångsrikt test en eller flera brister. Det är samma som TDD. När ett test misslyckas har du gjort framsteg eftersom du vet att du behöver lösa problemet.
• TDD säkerställer att ditt system faktiskt uppfyller kraven definierade för det. Det hjälper till att bygga ditt förtroende för ditt system.
• I TDD är mer fokus på produktionskod som verifierar om testning fungerar korrekt. Vid traditionell testning fokuseras mer på testfall design. Huruvida testet visar korrekt / felaktig körning av applikationen för att uppfylla kraven.
• I TDD uppnår du 100% täckningstest. Varje enskild kod testas, till skillnad från traditionell testning.
• Kombinationen av både traditionell testning och TDD leder till vikten av att testa systemet snarare än att systemet blir perfekt.
• I Agile Modeling (AM), bör du ”testa med ett syfte”. Du borde 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

1. Acceptance TDD (ATDD): Med ATDD skriver du ett enda acceptantest. Detta test uppfyller kraven i specifikationen eller uppfyller systemets beteende. Efter det skriver du bara tillräckligt med produktions- / funktionskod för att fullfölja det acceptantestet. Godkännande test fokuserar på systemets övergripande beteende. ATDD var också känt som BDD (Behavioral Driven Development).
2. Utvecklare TDD: Med utvecklare TDD skriver du enstaka utvecklartest, dvs. enhetstest och sedan bara tillräckligt med produktionskod för att uppfylla det testet. Enhetstestet fokuserar på alla små funktioner i systemet. Utvecklare TDD kallas helt enkelt som TDD.

   Huvudmålet för ATDD och TDD är att specificera detaljerade, körbara krav för din lösning på en just in time (JIT) -basis. JIT innebär att man endast tar de krav i beaktande som behövs i systemet. Så öka effektiviteten.

Skalning TDD via Agile Model Driven Development (AMDD)

TDD är mycket bra på detaljerad specifikation och validering. Det misslyckas med att tänka igenom större frågor som övergripande design, användning av systemet eller UI.AMDD hanterar Agile-skalningsproblem som TDD inte gör.

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

AMDD: s livscykel.

I Model-driven Development (MDD) skapas omfattande modeller innan källkoden är skriven. Vilka har i sin tur en smidig inställning?

I ovanstående figur representerar varje ruta en utvecklingsaktivitet.

Envisioning är en av TDD-processen för att förutsäga / föreställa tester som kommer att utföras under projektets första vecka. Huvudmålet med att föreställa sig är att identifiera systemets omfattning och arkitektur. Höga krav och arkitekturmodellering görs för framgångsrik planering.

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

1. Iteration 0: Envisioning

Det finns två huvudunderaktiveringar.

1. Föreställning om initiala krav.

   Det kan ta flera dagar att identifiera systemets höga krav och omfattning. Huvudfokus är att utforska användningsmodell, initial domänmodell och användargränssnittsmodell (UI).

2. Inledande arkitektonisk planering.

   Det tar också flera dagar att identifiera systemets arkitektur. Det gör det möjligt att ställa in tekniska anvisningar för projektet. Huvudfokus är att utforska teknologidiagram, användargränssnittsflöde (UI), domänmodeller och förändringsfall.

1. Iterationsmodellering:

   Här måste teamet planera det arbete som kommer att göras för varje iteration.

• Agil process används för varje iteration, det vill säga under varje iteration kommer nytt arbetsobjekt att läggas till med prioritet.
• Först högre prioriterat arbete kommer att beaktas. Arbetsartiklar som läggs till kan omprioriteras eller tas bort från objektstacken 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 ska implementeras för den iterationen.

1. Model storming:

   Detta kallas också Just in time Modeling.

• Här involverar modelleringssessioner ett team på 2/3 medlemmar som diskuterar frågor på papper eller whiteboard.
• En lagmedlem kommer att fråga en annan att modellera med dem. Denna modelleringssession tar cirka 5 till 10 minuter. Där teammedlemmar samlas för att dela whiteboard / paper.
• De utforskar frågor tills de inte hittar huvudorsaken till problemet. Precis i tid, om en teammedlem identifierar den fråga som han / hon vill ha för att lösa kommer han / hon att snabbt få 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 .

1. Test Driven Development (TDD).

• Det främjar bekräftande testning av din applikationskod och detaljerad specifikation.
• Både godkännandestest (detaljerade krav) och utvecklartester (enhetstest) är ingångar för TDD.
• TDD gör koden enklare och tydligare. Det gör att utvecklaren kan behålla mindre dokumentation.

1. Recensioner.

• Detta är valfritt. Det innehåller kodinspektioner och modellgranskningar.
• Detta kan vara gjort för varje iteration eller för hela projektet.
• Detta är ett bra alternativ för att ge feedback för projektet.

Test Driven Development (TDD) Vs. Agile Model Driven Development (AMDD)

Exempel på TDD

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

Ett villkor för godkännande av lösenord:

• Lösenordet bör vara mellan 5 och 10 tecken.

Först skriver vi koden som uppfyller alla ovanstående krav.

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

Vi kommer att springa över klass TestPassword ();

Utdata passeras enligt nedan.

Utgång:

Scenario 2: Här kan vi se i metod TestPasswordLength () det finns inget behov av att skapa en instans av klass PasswordValidator. Instans betyder att man skapar ett klassobjekt för att hänvisa medlemmarna (variabler / metoder) för den klassen.

Vi tar bort klassen PasswordValidator pv = new PasswordValidator () från koden. Vi kan ringa metoden isValid () direkt med PasswordValidator. IsValid (”Abc123”).(Se bilden nedan)

Så vi refaktorerar (byter kod) enligt nedan:

Scenario 3: Efter refactoring visar utgången misslyckad status (se bilden nedan) beror det på att vi har tagit bort förekomsten. Så det finns ingen hänvisning till icke-statisk metod isValid ().

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

Output:

Efter ändringar i klass PassValidator () om vi kör testet kommer utmatningen att klara sig som visas nedan.

Fördelar med TDD

• Tidigt fel underrättelse.

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

• Bättre utformad, renare och mer utdragbar kod.
  • Det hjälper dig 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 man skriver 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 för refaktor
  • Om du refaktorerar koden kan det finnas möjligheter till avbrott i koden. Så med en uppsättning automatiserade tester kan du fixa dessa pauser innan du släpper. Korrekt varning kommer att ges om pauser hittas när automatiska tester används.
  • Att använda TDD skulle resultera i snabbare, mer utdragbar kod med färre buggar som kan uppdateras med minimala risker.
• Bra för lagarbete

  I avsaknad av någon teammedlem kan andra teammedlemmar enkelt plocka upp och arbeta med koden. Det underlättar också kunskapsdelning, vilket gör teamet mer effektivt överlag.

• Bra för utvecklare

  Även om utvecklare måste spendera mer tid på att skriva TDD-testfall tar det mycket mindre tid för felsökning och utveckling av nya funktioner. Du kommer att skriva renare, mindre komplicerad kod.

Sammanfattning:

• TDD står för testdriven utveckling. Det är en process för att modifiera koden för att klara ett test som designats tidigare.
• Det är mer tonvikt på produktionskod snarare än testfall design.
• Testdriven utveckling är en process att ändra koden för att klara ett test som designats tidigare.
• Inom Software Engineering kallas det ibland ”Test First Development”.
• TDD inkluderar refaktorisering av en kod, dvs. att ändra / lägga till en viss mängd kod till den befintliga koden utan att påverka koden.
• TDD när den används blir koden tydligare och enkel att förstår.

Denna artikel har bidragit av Kanchan Kulkarni