Hva er testdrevet utvikling (TDD)? Eksempel

Hva er testdrevet utvikling (TDD)?

Testdrevet utvikling (TDD) er programvareutviklingstilnærming der testcases utvikles for å spesifisere og validere hva koden vil gjøre. Enkelt sagt, testtilfeller for hver funksjonalitet opprettes og testes først, og hvis testen mislykkes, skrives den nye koden for å bestå testen og gjøre koden enkel og feilfri.

Testdrevet utvikling starter med å designe og utvikle tester for hver liten funksjonalitet i en applikasjon. TDD-rammeverket instruerer utviklere til å skrive ny kode bare hvis en automatisert test har mislyktes. Dette unngår duplisering av kode. TDD full form er testdrevet utvikling.

Det enkle konseptet med TDD er å skrive og korrigere de mislykkede testene før du skriver ny kode (før utvikling). Dette bidrar til å unngå duplisering av kode da vi skriver en liten mengde kode om gangen for å bestå tester. (Tester er ikke annet enn kravbetingelser som vi må teste for å oppfylle dem).

Testdrevet utvikling er en prosess med å utvikle og kjøre automatiserte tester før faktisk utvikling av applikasjonen. Derfor kalles TDD noen ganger også som Test første utvikling.

Hvordan utføre TDD-testen

Følgende trinn definerer hvordan TDD-testen skal utføres,

Legg til en test.
Kjør alle testene og se om en ny test mislykkes.
Skriv litt kode.
Kjør tester og Refactor-kode.
Gjenta.

Utfør TDD-test — Fem trinn i testdrevet utvikling

TDD syklus definerer

Skriv en test
Få det til å løpe.
Endre koden for å gjøre den riktig, dvs. Refactor.
Gjenta prosessen.

Noen avklaringer om TDD:

TDD-tilnærmingen handler verken om "Testing" eller om "Design".
TDD betyr ikke "skriv noen av testene, og bygg deretter et system som består testene.
TDD betyr ikke "utfør mye testing."

TDD vs. Tradisjonell testing

Nedenfor er hovedforskjellen mellom testdrevet utvikling og tradisjonell testing:

TDD-tilnærming er først og fremst en spesifikasjonsteknikk. Det sikrer at kildekoden din blir grundig testet på bekreftende nivå.

Med tradisjonell testing finner en vellykket test en eller flere feil. Det er det samme som TDD. Når en test mislykkes, har du gjort fremskritt fordi du vet at du må løse problemet.
TDD sikrer at systemet ditt faktisk oppfyller kravene som er definert for det. Det bidrar til å bygge opp din tillit til systemet ditt.
I TDD er mer fokus på produksjonskode som verifiserer om testing vil fungere skikkelig. I tradisjonell testing er det mer fokus på testcase-design. Om testen vil vise riktig/feil utførelse av applikasjonen for å oppfylle kravene.
I TDD oppnår du 100 % dekningstest. Hver eneste kodelinje blir testet, i motsetning til tradisjonell testing.
Kombinasjonen av både tradisjonell testing og TDD fører til viktigheten av å teste systemet fremfor perfeksjon av systemet.
In Smidig modellering (AM), bør du "teste med en hensikt". Du bør vite hvorfor du tester noe og hvilket nivå det må testes.

Hva er aksept TDD og utvikler TDD

Det er to nivåer av TDD

Aksept TDD (ATDD): Med ATDD skriver du en enkelt akseptprøve. Denne testen oppfyller kravet i spesifikasjonen eller tilfredsstiller oppførselen til systemet. Etter det skriver du akkurat nok produksjons-/funksjonalitetskode til å oppfylle aksepttesten. Aksepttest fokuserer på den generelle oppførselen til systemet. ATDD ble også kjent som Atferdsdrevet utvikling (BDD).
Utvikler TDD: Med Developer TDD skriver du enkeltutviklertest dvs. enhetstest og deretter akkurat nok produksjonskode til å oppfylle den testen. Enhetstesten fokuserer på alle små funksjoner i systemet. Utvikler TDD kalles ganske enkelt som TDD.Hovedmålet til ATDD og TDD er å spesifisere detaljerte, kjørbare krav for løsningen din på en just in time (JIT) basis. JIT betyr kun å ta hensyn til de kravene som er nødvendige i systemet. Så øk effektiviteten.

Skalering av TDD via Agile Model Driven Development (AMDD)

TDD er veldig god på detaljerte spesifikasjoner og validering. Den klarer ikke å tenke gjennom større problemer som generell design, bruk av systemet eller brukergrensesnittet. AMDD tar tak i Agile-skaleringsproblemene som TDD ikke gjør.

Derfor brukes AMDD til større problemer.

Livssyklusen til AMDD

I Model-driven Development (MDD) lages omfattende modeller før kildekoden skrives. Som igjen har en smidig tilnærming?

I figuren ovenfor representerer hver boks en utviklingsaktivitet.

Envisioning er en av TDD-prosessene med å forutsi/forestille tester som vil bli utført i løpet av den første uken av prosjektet. Hovedmålet med å forestille seg er å identifisere omfanget av systemet og arkitekturen til systemet. Høynivåkrav og arkitekturmodellering gjøres for vellykket forestilling.

Det er prosessen hvor det ikke gjøres en detaljert spesifikasjon av programvare/system, men utforsker kravene til programvare/system som definerer den overordnede strategien for prosjektet.

Iterasjon 0: Envisioning

Det er to hovedsubaktiveringer.

Innledende krav ser for seg.Det kan ta flere dager å identifisere høynivåkrav og systemomfang. Hovedfokuset er å utforske bruksmodell, innledende domenemodell og brukergrensesnittmodell (UI).
Initial Architekturelle forestillinger. Det tar også flere dager å identifisere arkitekturen til systemet. Det lar deg sette tekniske retningslinjer for prosjektet. Hovedfokuset er å utforske teknologidiagrammer, flyt av brukergrensesnitt (UI), domenemodeller og endringstilfeller.

Iterasjonsmodellering

Her må teamet planlegge arbeidet som skal gjøres for hver iterasjon.

Agile prosess brukes for hver iterasjon, dvs. under hver iterasjon vil nytt arbeidselement bli lagt til med prioritet.
Først høyere prioritert arbeid vil bli tatt i betraktning. Arbeidselementer som legges til kan omprioriteres eller fjernes fra stabelen av elementer når som helst.
Teamet diskuterer hvordan de skal implementere hvert krav. Modellering brukes til dette formålet.
Modelleringsanalyse og design gjøres for hvert krav som skal implementeres for den iterasjonen.

Modellstorming

Dette er også kjent som Just in time Modeling.

Her involverer modelleringsøkten et team på 2/3 medlemmer som diskuterer saker på papir eller tavle.
Ett teammedlem vil be en annen om å modellere med dem. Denne modelløkten vil ta omtrent 5 til 10 minutter. Hvor teammedlemmer samles for å dele tavle/papir.
De utforsker problemer til de ikke finner hovedårsaken til problemet. Akkurat i tide, hvis ett teammedlem identifiserer problemet som han/hun ønsker å løse, vil han/hun ta rask hjelp av andre teammedlemmer.
Andre gruppemedlemmer utforsker deretter problemet, og så fortsetter alle som før. Det kalles også som stand-up modellering eller kunde QA-økter.

Testdrevet utvikling (TDD)

Det fremmer bekreftende testing av søknadskoden din og detaljerte spesifikasjoner.
Både aksepttest (detaljerte krav) og utviklertester (enhetstest) er input for TDD.
TDD gjør koden enklere og oversiktlig. Det lar utvikleren vedlikeholde mindre dokumentasjon.

Anmeldelser

Dette er valgfritt. Det inkluderer kodeinspeksjoner og modellgjennomganger.
Dette kan gjøres for hver iterasjon eller for hele prosjektet.
Dette er et godt alternativ for å gi tilbakemelding på prosjektet.

Testdrevet utvikling (TDD) vs. Agile modelldrevet utvikling (AMDD)

TDD	AMDD
TDD forkorter tilbakemeldingssløyfen for programmering	AMDD forkorter tilbakemeldingssløyfe for modellering.
TDD er detaljert spesifikasjon	AMDD fungerer for større problemer
TDD fremmer utviklingen av kode av høy kvalitet	AMDD fremmer kommunikasjon av høy kvalitet med interessenter og utviklere.
TDD snakker med programmerere	AMDD snakker med Business Analyst, interessenter og dataeksperter.
TDD ikke-visuelt orientert	AMDD visuelt orientert
TDD har begrenset omfang til programvareverk	AMDD har et bredt virkeområde, inkludert interessenter. Det innebærer å jobbe mot en felles forståelse
Begge støtter evolusjonær utvikling	---------------

TDD-rammeverk

Her er listen over beste rammeverk for testdrevet utvikling (TDD).

Junite
TestNG
csUnit og NUnit
Rspec

La oss nå lære testdrevet utvikling ved et eksempel.

Eksempel på TDD

Her i dette testdrevne utviklingseksemplet vil vi definere et klassepassord. For denne klassen vil vi prøve å tilfredsstille følgende betingelser.

En betingelse for passordgodkjenning:

Passordet skal være mellom 5 og 10 tegn.

Først i dette TDD-eksemplet skriver vi koden som oppfyller alle kravene ovenfor.

Scenario 1: For å kjøre testen lager vi klassen PasswordValidator ();

Vi vil kjøre over klassen TestPassword ();

Utgangen er PASSERT som vist nedenfor;

Produksjon:

Scenario 2: Her kan vi se i metoden TestPasswordLength () at det ikke er behov for å lage en forekomst av klassen PasswordValidator. Forekomst betyr å opprette en objekt av klassen for å referere medlemmene (variabler/metoder) i den klassen.

Vi vil fjerne klassen PasswordValidator pv = new PasswordValidator () fra koden. Vi kan ringe er gyldig () metode direkte av Passordvalidator. IsValid ("Abc123"). (Se bildet under)

Så vi Refactor (endre kode) som nedenfor:

Scenario 3: Etter refaktorisering viser utdata mislykket status (se bildet nedenfor) dette er fordi vi har fjernet forekomsten. Så det er ingen referanse til ikke-statisk metode er gyldig ().

Så vi må endre denne metoden ved å legge til "statisk" ord før boolsk som offentlig statisk boolsk isValid (strengpassord). Refactoring Class PasswordValidator () for å fjerne feilen ovenfor for å bestå testen.

Utgang:

Etter å ha gjort endringer i klassen PassValidator () hvis vi kjører testen, vil utdata bli PASSERT som vist nedenfor.

Fordeler med TDD

Følgende er hovedfordelene med testdrevet utvikling i programvareteknikk:

Tidlig feilvarsling.

Utviklere tester koden sin, men i databaseverdenen består dette ofte av manuelle tester eller engangsskript. Ved å bruke TDD bygger du over tid opp en pakke med automatiserte tester som du og enhver annen utviklere kan kjøre på nytt etter eget ønske.

Bedre designet, renere og mer utvidbar kode.

Det hjelper å forstå hvordan koden skal brukes og hvordan den samhandler med andre moduler.
Det resulterer i bedre designbeslutninger og mer vedlikeholdbar kode.
TDD gjør det mulig å skrive mindre kode med enkelt ansvar i stedet for monolitiske prosedyrer med flere ansvarsområder. Dette gjør koden enklere å forstå.
TDD tvinger også til å skrive kun produksjonskode for å bestå tester basert på brukerkrav.

Tillit til Refactor

Hvis du refactorer koder, kan det være muligheter for brudd i koden. Så med et sett med automatiserte tester kan du fikse disse pausene før utgivelsen. Riktig advarsel vil bli gitt hvis det oppdages brudd når automatiserte tester brukes.
Bruk av TDD bør resultere i raskere, mer utvidbar kode med færre feil som kan oppdateres med minimal risiko.

Bra for teamarbeid

I fravær av et teammedlem kan andre teammedlemmer enkelt plukke opp og jobbe med koden. Det hjelper også med kunnskapsdeling, og gjør dermed teamet mer effektivt totalt sett.

Bra for utviklere

Selv om utviklere må bruke mer tid på å skrive TDD-testsaker, tar det mye mindre tid for feilsøking og utvikling av nye funksjoner. Du vil skrive renere, mindre komplisert kode.

Sammendrag

TDD står for testdrevet utvikling.
TDD-betydning: Det er en prosess for å modifisere koden for å bestå en test designet tidligere.
Det legger mer vekt på produksjonskode i stedet for testcase-design.
Testdrevet utvikling er en prosess for å modifisere koden for å bestå en test designet tidligere.
In Engineering programvare, Det er noen ganger kjent som "Test første utvikling."
TDD-testing inkluderer refaktorisering av en kode, dvs. endre/legge til en viss mengde kode til den eksisterende koden uten å påvirke oppførselen til koden.
Når TDD-programmering brukes, blir koden klarere og enkel å forstå.