Testdriven utveckling
Test Driven Development (TDD) är en metod för utveckling av programvara där testfall utvecklas för att specificera och validera vad koden kommer att göra. I enkla termer 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 felfri.
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 misslyckade tester 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 automatiskt test innan den faktiska utvecklingen av applikationen. Därför kallas TDD ibland också som Test First Development.
I den här handledningen lär du dig mer om-
- Hur man utför TDD-test
- TDD Vs. Traditionell testning
- Vad är acceptans TDD och utvecklare TDD
- Skalning av 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,
- Lägg till ett test.
- Kör alla tester och se om något nytt test misslyckas.
- Skriv lite kod.
- Kör tester och refaktorkod.
- Upprepa.
TDD-cykel definierar
- Skriv ett test
- Låt det köra.
- Ändra koden så att den blir rätt, dvs Refactor.
- Upprepa processen.
Några förtydliganden om TDD:
- TDD handlar varken om "Testing" eller om "Design".
- TDD betyder inte "skriv några av testerna, bygg sedan ett system som klarar testerna.
- TDD betyder inte "gör massor av testning."
TDD Vs. Traditionell testning
TDD-tillvägagångssätt är främst en specifikationsteknik. Det säkerställer att din källkod testas grundligt på bekräftande nivå.
- Med traditionell testning hittar ett framgångsrikt test ett eller flera fel. 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 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 / felaktigt genomförande av ansökan för att uppfylla kraven.
- I TDD uppnår du 100% täckningstest. Varje rad 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 är perfekt.
- I Agile Modelling (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
- 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).
- Utvecklare TDD: Med utvecklare TDD skriver du enstaka utvecklartest, dvs. enhetstest och sedan tillräckligt med produktionskod för att uppfylla detta test. 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 av 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 användargränssnitt. AMDD åtgärdar Agile-skalningsproblem som TDD inte gör.
Således använde AMDD för större problem.
Livscykeln för AMDD.
I Model-driven Development (MDD) skapas omfattande modeller innan källkoden skrivs. Vilka har i sin tur en smidig inställning?
I figuren ovan 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.
- Iteration 0: Envisioning
Det finns två huvudunderaktiveringar.
- Initiala förutsättningar.
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).
- Inledande arkitektonisk planering.
Det tar också flera dagar att identifiera systemets arkitektur. Det gör det möjligt att ställa in tekniska riktningar för projektet. Huvudfokus är att utforska teknologidiagram, användargränssnittsflöde (UI), domänmodeller och förändringsfall.
- 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örsta högre prioriterade 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 genomföra 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.
- Model storming:
Detta är också känt som 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 be en annan att modellera med dem. Denna modelleringssession tar cirka 5 till 10 minuter. Där teammedlemmar samlas för att dela whiteboard / papper.
- De utforskar frågor tills de inte hittar huvudorsaken till problemet. Precis i tid, om en teammedlem identifierar problemet som han / hon vill 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.
- 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.
- Recensioner.
- Detta är valfritt. Den innehåller 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.
Test Driven Development (TDD) Vs. Agile Model Driven Development (AMDD)
| TDD | AMDD |
|
|
|
|
|
|
|
|
|
|
|
|
| -------------------------------------------- |
Exempel på TDD
Här i det här exemplet 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 ();
Output är PASSAD som visas 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 klass PasswordValidator pv = nytt 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.
Produktion:
Efter att ha gjort ändringar i klass PassValidator () om vi kör testet kommer PASSET att klara sig som visas nedan.
Fördelar med TDD
- Tidig felanmälan.
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 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 gör det möjligt 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 för refaktor
- Om du omaktiverar 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 upptäcks när automatiska tester används.
- Att använda TDD bör 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 ändra koden för att klara ett test som designats tidigare.
- Det lägger större vikt vid produktionskod snarare än design av testfall.
- Testdriven utveckling är en process för att modifiera koden för att klara ett tidigare designat test.
- Inom programvaruteknik kallas det ibland som "Test First Development."
- TDD inkluderar refaktorisering av en kod, dvs. att ändra / lägga till en viss mängd kod i den befintliga koden utan att påverka kodens beteende.
- TDD när den används blir koden tydligare och enkel att förstå.
Denna artikel har bidragit av Kanchan Kulkarni