Hvad er TDD (Test Driven Development)? Tutorial med eksempel

Indholdsfortegnelse:

Anonim

Testdrevet udvikling

Test Driven Development (TDD) er en softwareudviklingsmetode, hvor testcases udvikles for at specificere og validere, hvad koden vil gøre. Enkelt sagt oprettes og testes testcases for hver funktionalitet 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 at designe og udvikle tests til hver lille funktionalitet i en applikation. TDD beder udviklere om kun at skrive ny kode, hvis en automatiseret test mislykkedes. Dette undgår duplikering af kode. Den fulde form for TDD er testdrevet udvikling.

Det enkle 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å test. (Test er intet andet end kravbetingelser, som vi skal teste for at opfylde dem).

Testdrevet udvikling er en proces til udvikling og kørsel af automatiseret test inden faktisk udvikling af applikationen. Derfor kaldes TDD undertiden også som Test First Development.

I denne vejledning lærer du mere om-

  • Sådan udføres TDD-test
  • TDD Vs. Traditionel testning
  • Hvad er accept TDD og Developer TDD
  • Skalering af TDD via Agile Model Driven Development (AMDD)
  • Test Driven Development (TDD) Vs. Agile Model Driven Development (AMDD)
  • Eksempel på TDD
  • Fordele ved TDD

Sådan udføres TDD-test

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

  1. Tilføj en test.
  2. Kør alle test og se om nogen ny test mislykkes.
  3. Skriv noget kode.
  4. Kør tests og refaktorkode.
  5. Gentage.

TDD-cyklus definerer

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

Nogle afklaringer om TDD:

  • TDD handler hverken om "Testing" eller om "Design".
  • TDD betyder ikke "skriv nogle af testene, bygg derefter et system, der består testene.
  • TDD betyder ikke "gør masser af test."

TDD Vs. Traditionel testning

TDD-tilgang er primært en specifikationsteknik. Det sikrer, at din kildekode testes grundigt 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 faktisk opfylder de krav, der er defineret til det. Det hjælper med at opbygge din tillid til dit system.
  • I TDD er der mere fokus på produktionskode, der verificerer, om test fungerer korrekt. I traditionel test er der mere fokus på test case design. Om testen viser korrekt / forkert udførelse af applikationen for at opfylde kravene.
  • I TDD opnår du 100% dækningstest. Hver eneste linje kode testes i modsætning til traditionel test.
  • Kombinationen af ​​både traditionel test og TDD fører til vigtigheden af ​​at teste systemet i stedet for perfektion af systemet.
  • I Agile Modelling (AM) skal du "teste med et formål". Du bør vide, hvorfor du tester noget, og hvilket niveau dets behov for at blive testet.

Hvad er accept TDD og Developer TDD

Der er to niveauer af TDD

  1. Acceptance TDD (ATDD): Med ATDD skriver du en enkelt accept test. Denne test opfylder kravene i specifikationen eller tilfredsstiller systemets opførsel. Derefter skriver du lige nok produktion / funktionalitetskode til at udføre den acceptstest. Acceptanstest fokuserer på systemets samlede opførsel. ATDD blev også kendt som Behavioral Driven Development (BDD).
  2. Udvikler TDD: Med udvikler TDD skriver du en enkelt udvikler test, dvs. enhedstest og derefter lige nok produktionskode til at udføre 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å en just in time (JIT) basis. JIT betyder kun at tage de krav i betragtning, der er nødvendige i systemet. Så øg effektiviteten.

Skalering af TDD via Agile Model Driven Development (AMDD)

TDD er meget god til detaljeret specifikation og validering. Det undlader at tænke igennem større problemer som overordnet design, brug af systemet eller UI. AMDD løser de agile skaleringsproblemer, som TDD ikke gør.

Således brugte AMDD til større problemer.

AMDD's livscyklus.

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

I ovenstående figur repræsenterer hvert felt en udviklingsaktivitet.

Envisioning er en af ​​TDD-processen til forudsigelse / forestilling af tests, der vil blive udført i løbet af projektets første uge. Hovedmålet med forestillingen er at identificere systemets omfang og systemets arkitektur. Krav på højt niveau og arkitekturmodellering udføres for en 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 den overordnede strategi for projektet.

  1. Iteration 0: Envisioning

Der er to hovedunderaktiveringer.

  1. Indledende forudsætninger.

    Det kan tage flere dage at identificere systemkrav på højt niveau og omfang. Hovedfokus er at udforske brugsmodel, indledende domænemodel og brugergrænseflademodel (UI).

  2. Indledende arkitektonisk forestilling.

    Det tager også flere dage at identificere systemets arkitektur. Det giver mulighed for at indstille tekniske retninger for projektet. Hovedfokus er at udforske teknologidiagrammer, brugergrænseflade (UI) flow, domænemodeller og Change cases.

  1. Iterationsmodellering:

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

  • Agil proces bruges til hver iteration, dvs. under hver iteration tilføjes nyt arbejdsemne med prioritet.
  • Første højere prioriterede arbejde vil blive taget i betragtning. Arbejdsgenstande, der tilføjes, kan når som helst omprioriteres eller fjernes fra varestakken.
  • Holdet diskuterer, hvordan de skal implementere hvert krav. Modellering bruges til dette formål.
  • Modelleringsanalyse og design udføres for hvert krav, der skal implementeres for den iteration.
  1. Model storming:

    Dette er også kendt som Just in time Modeling.

  • Her involverer modelleringssessionen et team på 2/3 medlemmer, der diskuterer spørgsmål på papir eller whiteboard.
  • Et teammedlem beder en anden om at modellere med dem. Denne modelleringssession tager cirka 5 til 10 minutter. Hvor teammedlemmer samles for at dele tavle / papir.
  • De udforsker problemer, indtil de ikke finder hovedårsagen til problemet. Lige i tide, hvis et teammedlem identificerer det problem, som han / hun vil 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.
  1. Test Driven Development (TDD).
  • Det fremmer bekræftende test af din applikationskode og detaljeret specifikation.
  • Både acceptstest (detaljerede krav) og udviklertests (enhedstest) er input til TDD.
  • TDD gør koden enklere og tydeligere. Det giver udvikleren mulighed for at vedligeholde mindre dokumentation.
  1. Anmeldelser.
  • Dette er valgfrit. Det inkluderer kodeinspektioner og modelanmeldelser.
  • Dette kan gøres for hver iteration eller for hele projektet.
  • Dette er en god mulighed for at give feedback til projektet.

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

TDD AMDD
  • TDD forkorter programmeringsfeedback-sløjfen
  • AMDD forkorter modelleringsfeedback 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 forretningsanalytikere, interessenter og dataprofessionelle.
  • TDD ikke-visuelt orienteret
  • AMDD visuelt orienteret
  • TDD har begrænset rækkevidde til softwareværker
  • AMDD har et bredt anvendelsesområde inklusive interessenter. Det indebærer at arbejde hen imod en fælles forståelse
  • Begge understøtter evolutionær udvikling
 --------------------------------------------

Eksempel på TDD

Her i dette eksempel definerer vi et 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 skriver vi koden, der opfylder alle ovenstående krav.

Scenarie 1 : For at køre testen opretter vi klasse PasswordValidator ();

Vi løber over klasse TestPassword ();

Output passeres som vist nedenfor;

Output :

Scenarie 2 : Her kan vi se i metode TestPasswordLength () er der ikke behov for at oprette en forekomst af klasse PasswordValidator. Forekomst betyder oprettelse af et objekt i klassen for at henvise medlemmerne (variabler / metoder) til den klasse.

Vi fjerner klasse PasswordValidator pv = ny PasswordValidator () fra koden. Vi kan kalde metoden isValid () direkte med PasswordValidator. IsValid ("Abc123") . (Se billedet nedenfor)

Så vi refaktorer (skift kode) som nedenfor:

Scenarie 3 : Efter refactoring viser output mislykket status (se billedet nedenfor), fordi det er, at vi har fjernet forekomsten. Så der er ingen henvisning til ikke-statisk metode isValid ().

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

Produktion:

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

Fordele ved TDD

  • Tidlig fejlmeddelelse.

    Udviklere tester deres kode, men i databaseverdenen består dette ofte af manuelle tests eller engangs-scripts. Ved hjælp af TDD opbygger du over tid en række automatiske tests, som du og enhver anden udvikler kan køre igen efter eget valg.

  • Bedre designet, renere og mere udvidelig kode.
    • Det hjælper med at forstå, hvordan koden skal bruges, og hvordan den interagerer med andre moduler.
    • Det resulterer i bedre designbeslutning og mere vedligeholdelig kode.
    • TDD tillader skrivning af mindre kode med et 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å tests baseret på brugerkrav.
  • Tillid til refactor
    • Hvis du refaktorerer kode, kan der være muligheder for pauser i koden. Så hvis du har et sæt automatiserede tests, kan du rette disse pauser inden udgivelsen. Korrekt advarsel gives, hvis der findes pauser, når automatiske tests bruges.
    • Brug af TDD burde resultere i hurtigere, mere udvidelig kode med færre fejl, der kan opdateres med minimale risici.
  • God til teamwork

    I mangel af noget teammedlem kan andre teammedlemmer let samle op og arbejde på koden. Det hjælper også videndeling og derved gør teamet mere effektivt generelt.

  • Godt for udviklere

    Selvom udviklere skal bruge mere tid på at skrive TDD-testsager, tager det meget mindre tid at debugge og udvikle nye funktioner. Du vil skrive renere, mindre kompliceret kode.

Resumé:

  • TDD står for testdrevet udvikling. Det er en proces til at ændre koden for at bestå en tidligere designet test.
  • Det lægger mere vægt på produktionskode snarere end test case design.
  • Test-drevet udvikling er en proces til at ændre koden for at bestå en test designet tidligere.
  • Inden for softwareteknik er det undertiden kendt som "Test First Development."
  • TDD inkluderer refaktorisering af en kode, dvs. ændring / tilføjelse af en vis mængde kode til den eksisterende kode uden at påvirke kodens opførsel.
  • TDD, når den bruges, bliver koden klarere og enkel at forstå.

Denne artikel er bidraget af Kanchan Kulkarni