Hvad er testdrevet udvikling (TDD)? Eksempel

Hvad er testdrevet udvikling (TDD)?

Testdrevet udvikling (TDD) er softwareudviklingstilgang, hvor testcases udvikles for at specificere og validere, hvad koden vil gøre. Enkelt sagt, testcases for hver funktionalitet oprettes og testes først, og hvis testen mislykkes, skrives den nye kode for at bestå testen og gøre koden enkel og fejlfri.

Testdrevet udvikling starter med design og udviklingping test for hver eneste lille funktionalitet i en applikation. TDD-frameworket instruerer udviklere i kun at skrive ny kode, hvis en automatiseret test er mislykket. Dette undgår dobbeltarbejde. Den fulde form af TDD er testdrevet udvikling.

Det simple koncept med TDD er at skrive og rette de mislykkede tests, før du skriver ny kode (før udvikling). Dette hjælper med at undgå duplikering af kode, da vi skriver en lille mængde kode ad gangen for at bestå tests. (Tester er intet andet end kravbetingelser, som vi skal teste for at opfylde dem).

Testdrevet udvikling er en udviklingsprocesping og kører automatiseret test før den faktiske udvikling af applikationen. Derfor kaldes TDD undertiden også for Test første udvikling.

Sådan udføres TDD-testen

Følgende trin definerer, hvordan man udfører TDD-test,

1. Tilføj en test.
2. Kør alle test og se, om en ny test mislykkes.
3. Skriv noget kode.
4. Kør test og Refactor-kode.
5. Gentage.

TDD cyklus definerer

1. Skriv en test
2. Få det til at køre.
3. Skift koden for at gøre den rigtig, dvs. Refactor.
4. Gentag processen.

Nogle præciseringer om TDD:

• TDD-tilgangen handler hverken om "Test" eller om "Design".
• TDD betyder ikke "skriv nogle af testene, og byg derefter et system, der består testene.
• TDD betyder ikke "udfør en masse test."

TDD vs. Traditionel test

Nedenfor er hovedforskellen mellem testdrevet udvikling og traditionel test:

TDD tilgang er primært en specifikationsteknik. Det sikrer, at din kildekode er grundigt testet på bekræftende niveau.

• Med traditionel test finder en vellykket test en eller flere defekter. Det er det samme som TDD. Når en test mislykkes, har du gjort fremskridt, fordi du ved, at du skal løse problemet.
• TDD sikrer, at dit system rent faktisk opfylder de krav, der er defineret for det. Det hjælper med at opbygge din tillid til dit system.
• I TDD er der mere fokus på produktionskode, der verificerer, om test vil fungere korrekt. I traditionel test er der mere fokus på design af testcase. Om testen vil vise den korrekte/ukorrekte udførelse af applikationen for at opfylde kravene.
• I TDD opnår du 100% dækningstest. Hver enkelt kodelinje testes i modsætning til traditionel test.
• Kombinationen af ​​både traditionel test og TDD fører til vigtigheden af ​​at teste systemet frem for perfektion af systemet.
• In Agile modellering (AM), bør du "teste med et formål". Du bør vide, hvorfor du tester noget, og hvilket niveau det skal testes.

Hvad er accept TDD og udvikler TDD

Der er to niveauer af TDD

1. Accept TDD (ATDD): Med ATDD skriver du en enkelt accepttest. Denne test opfylder kravene i specifikationen eller tilfredsstiller systemets opførsel. Skriv derefter lige nok produktions-/funktionalitetskode til at opfylde denne accepttest. Accepttest fokuserer på systemets overordnede adfærd. ATDD var også kendt som Behavioural Driven Development (BDD).
2. Udvikler TDD: Med Developer TDD skriver du en enkelt udviklertest, dvs. enhedstest og derefter lige nok produktionskode til at opfylde denne test. Enhedstesten fokuserer på hver eneste lille funktionalitet i systemet. Udvikler TDD kaldes simpelthen som TDD.Hovedmålet med ATDD og TDD er at specificere detaljerede, eksekverbare krav til din løsning på et just in time (JIT) grundlag. JIT betyder kun at tage de krav i betragtning, som er nødvendige i systemet. Så øge effektiviteten.

Skalering af TDD via Agile Model Driven Development (AMDD)

TDD er meget god til detaljerede specifikationer og validering. Den formår ikke at gennemtænke større problemer såsom overordnet design, brug af systemet eller brugergrænseflade. AMDD løser problemer med Agile skalering, som TDD ikke gør.

Således AMDD brugt til større problemer.

AMDDs livscyklus

I Model-driven Development (MDD) oprettes omfattende modeller før kildekoden skrives. Som igen har en agil tilgang?

I ovenstående figur repræsenterer hver boks en udviklingsaktivitet.

Envisioning er en af ​​TDD-processerne med forudsigelse/forestillingstest, som vil blive udført i løbet af den første uge af projektet. Hovedmålet med envisioning er at identificere omfanget af systemet og systemets arkitektur. Krav og arkitekturmodellering på højt niveau udføres for vellykket forestilling.

Det er processen, hvor der ikke udføres en detaljeret specifikation af software/system, men udforskning af kravene til software/system, der definerer projektets overordnede strategi.

Iteration 0: Envisioning

Der er to primære underaktiveringer.

1. Indledende krav forestillende.Det kan tage flere dage at identificere høje krav og omfang af systemet. Hovedfokus er at udforske brugsmodel, indledende domænemodel og brugergrænseflademodel (UI).
2. Initial Architeknisk forestilling. Det tager også flere dage at identificere systemets arkitektur. Det giver mulighed for at sætte tekniske retningslinjer for projektet. Hovedfokus er at udforske teknologidiagrammer, User Interface (UI) flow, domænemodeller og Change cases.

Iterationsmodellering

Her skal teamet planlægge det arbejde, der skal udføres for hver iteration.

• Agile proces bruges til hver iteration, dvs. under hver iteration vil nyt arbejdsemne blive tilføjet med prioritet.
• Det første højere prioriterede arbejde vil blive taget i betragtning. Arbejdselementer, der tilføjes, kan til enhver tid omprioriteres eller fjernes fra stablen af ​​elementer.
• Teamet diskuterer, hvordan de vil implementere hvert enkelt krav. Modellering bruges til dette formål.
• Modelleringsanalyse og design udføres for hvert krav, som skal implementeres for den iteration.

Model stormende

Dette er også kendt som Just in time Modeling.

• Her involverer modelleringssession et team på 2/3 medlemmer, som diskuterer spørgsmål på papir eller tavle.
• Et teammedlem vil bede et andet om at modellere med dem. Denne modelleringssession vil tage cirka 5 til 10 minutter. Hvor teammedlemmer samles for at dele whiteboard/papir.
• De udforsker problemer, indtil de ikke finder hovedårsagen til problemet. Lige i tide, hvis et teammedlem identificerer det problem, han/hun ønsker at løse, vil han/hun tage hurtig hjælp fra andre teammedlemmer.
• Andre gruppemedlemmer udforsker derefter problemet, og så fortsætter alle som før. Det kaldes også som stand-up modellering eller kunde QA sessioner.

Testdrevet udvikling (TDD)

• Det fremmer bekræftende test af din ansøgningskode og detaljerede specifikationer.
• Både accepttest (detaljerede krav) og udviklertest (enhedstest) er input til TDD.
• TDD gør koden enklere og overskuelig. Det giver udvikleren mulighed for at vedligeholde mindre dokumentation.

Reviews

• Dette er valgfrit. Det inkluderer kodeinspektioner og modelgennemgange.
• Dette kan gøres for hver iteration eller for hele projektet.
• Dette er en god mulighed for at give feedback til projektet.

Testdrevet udvikling (TDD) vs. Agile modeldrevet udvikling (AMDD)

TDD	AMDD
TDD forkorter programmeringsfeedbacksløjfen	AMDD forkorter modellering feedback loop.
TDD er detaljeret specifikation	AMDD arbejder for større problemer
TDD fremmer udviklingen af ​​kode af høj kvalitet	AMDD fremmer kommunikation af høj kvalitet med interessenter og udviklere.
TDD taler til programmører	AMDD taler med Business Analyst, interessenter og dataprofessionelle.
TDD ikke-visuelt orienteret	AMDD visuelt orienteret
TDD har begrænset omfang til softwarearbejde	AMDD har et bredt anvendelsesområde, herunder interessenter. Det handler om at arbejde hen imod en fælles forståelse
Begge understøtter evolutionær udvikling	---------------

TDD Frameworks

Her er listen over de bedste testdrevne udviklingsrammer (TDD).

1. Junit
2. TestNG
3. csUnit og NUnit
4. Rspec

Lad os nu lære Testdrevet udvikling ved eksempel.

Eksempel på TDD

Her i dette testdrevne udviklingseksempel vil vi definere en klasseadgangskode. For denne klasse vil vi forsøge at opfylde følgende betingelser.

En betingelse for accept af adgangskode:

• Adgangskoden skal være mellem 5 og 10 tegn.

Først i dette TDD-eksempel skriver vi koden, der opfylder alle ovenstående krav.

Scenario 1: For at køre testen opretter vi klassen PasswordValidator ();

Vi kører over klassen TestPassword ();

Outputtet er bestået som vist nedenfor;

Produktion:

Scenario 2: Her kan vi se i metoden TestPasswordLength () at der ikke er behov for at oprette en forekomst af klassen PasswordValidator. Forekomst betyder at oprette en objekt klasse for at henvise medlemmerne (variabler/metoder) af den pågældende klasse.

Vi fjerner klassen PasswordValidator pv = new PasswordValidator () fra koden. Vi kan ringe til er gyldig () metode direkte ved Password Validator. IsValid ("Abc123"). (Se billedet nedenfor)

Så vi Refactor (ændre kode) som nedenfor:

Scenario 3: Efter refactoring viser outputtet mislykket status (se billedet nedenfor), det skyldes, at vi har fjernet instansen. Så der er ingen reference til ikke-statisk metode er gyldig ().

Så vi er nødt til at ændre denne metode ved at tilføje "statisk" ord før Boolean som offentlig statisk boolean isValid (strengadgangskode). Refactoring Class PasswordValidator () for at fjerne ovenstående fejl for at bestå testen.

Output:

Efter at have foretaget ændringer i klassen PassValidator (), hvis vi kører testen, vil outputtet blive bestået som vist nedenfor.

Fordele ved TDD

Følgende er de vigtigste fordele ved Test Driven Development in Software Engineering:

Tidlig fejlmeddelelse.

• Udviklere tester deres kode, men i databaseverdenen består dette ofte af manuelle tests eller enkeltstående scripts. Ved at bruge TDD opbygger du over tid en række automatiserede tests, som du og enhver anden udvikler kan køre igen efter eget ønske.

Bedre designet, renere og mere udvidelsesbar kode.

• Det hjælper med at forstå, hvordan koden vil blive brugt, og hvordan den interagerer med andre moduler.
• Det resulterer i bedre designbeslutninger og mere vedligeholdelsesvenlig kode.
• TDD gør det muligt at skrive mindre kode med enkelt ansvar i stedet for monolitiske procedurer med flere ansvarsområder. Dette gør koden lettere at forstå.
• TDD tvinger også til kun at skrive produktionskode for at bestå test baseret på brugerkrav.

Tillid til Refactor

• Hvis du refactorer koder, kan der være muligheder for brud i koden. Så med et sæt automatiserede tests kan du rette disse pauser før frigivelse. Korrekt advarsel vil blive givet, hvis der konstateres pauser, når der anvendes automatiserede tests.
• Brug af TDD bør resultere i hurtigere, mere udvidelsesbar kode med færre fejl, der kan opdateres med minimale risici.

God til teamwork

• I mangel af et teammedlem kan andre teammedlemmer nemt samle op og arbejde på koden. Det hjælper også med at dele viden, og derved gøre teamet mere effektivt generelt.

Godt for udviklere

• Selvom udviklere skal bruge mere tid på at skrive TDD-testcases, tager det meget mindre tid til fejlfinding og udvikling.ping nye funktioner. Du vil skrive renere og mindre kompliceret kode.

Ofte Stillede Spørgsmål