Mis on testpõhine arendus (TDD)? Õpetus koos näitega

Testpõhine areng

Testpõhine arendus (TDD) on tarkvaraarenduslik lähenemisviis, mille käigus töötatakse välja testjuhtumid, et täpsustada ja kinnitada, mida kood teeb. Lihtsamalt öeldes luuakse ja testitakse kõigepealt iga funktsionaalsuse testijuhtumeid ja kui test ebaõnnestub, kirjutatakse uus kood testi läbimiseks ning koodi lihtsaks ja veatuks muutmiseks.

Testpõhine arendus algab testide väljatöötamise ja arendamisega rakenduse iga väikese funktsionaalsuse jaoks. TDD käsib arendajatel kirjutada uus kood ainult juhul, kui automatiseeritud test on ebaõnnestunud. See väldib koodi dubleerimist. TDD täielik vorm on testpõhine arendus.

TDD lihtne mõte on ebaõnnestunud testide kirjutamine ja parandamine enne uue koodi kirjutamist (enne arendamist). See aitab vältida koodi dubleerimist, kuna testide läbimiseks kirjutame korraga väikese koguse koodi. (Testid pole muud kui nõudetingimused, mida peame nende täitmiseks testima).

Testpõhine arendus on automatiseeritud testi väljatöötamise ja käitamise protsess enne rakenduse tegelikku väljatöötamist. Seetõttu nimetati TDD-d mõnikord ka test First Development'iks.

Selles õpetuses saate lisateavet

• Kuidas teha TDD-testi
• TDD vs. Traditsiooniline testimine
• Mis on aktsepteerimise TDD ja arendaja TDD
• TDD skaleerimine agiilse mudelipõhise arenduse (AMDD) kaudu
• Testpõhine areng (TDD) vs. Agile mudelipõhine arendus (AMDD)
• TDD näide
• TDD eelised

Kuidas teha TDD-testi

Järgmised sammud määratlevad, kuidas TDD-testi teha

1. Lisage test.
2. Käivitage kõik testid ja vaadake, kas mõni uus test ebaõnnestub.
3. Kirjutage kood.
4. Käivitage testid ja Refactori kood.
5. Korda.

TDD tsükkel määratleb

1. Kirjutage test
2. Pane see käima.
3. Muutke kood õigeks, st Refactor.
4. Korda protsessi.

Mõned selgitused TDD kohta:

• TDD ei ole seotud "testimisega" ega "disainiga".
• TDD ei tähenda, et "kirjutage mõned testid, seejärel ehitage süsteem, mis testid läbib.
• TDD ei tähenda "tee palju teste".

TDD vs. Traditsiooniline testimine

TDD lähenemine on peamiselt spetsifikatsioonitehnika. See tagab, et teie lähtekoodi testitakse põhjalikult kinnitusastmel.

• Traditsioonilise testimise korral leiab edukas test ühe või mitu defekti. See on sama mis TDD. Kui test ebaõnnestub, olete edenenud, sest teate, et peate probleemi lahendama.
• TDD tagab, et teie süsteem vastab tegelikult sellele määratletud nõuetele. See aitab suurendada teie usaldust oma süsteemi suhtes.
• TDD-s keskendutakse rohkem tootekoodile, mis kontrollib, kas testimine töötab korralikult. Traditsioonilises testimises pööratakse rohkem tähelepanu juhtumite kujundamisele. Kas test näitab nõuetekohase rakenduse nõuetekohast / sobimatut täitmist?
• TDD-s saavutate 100% katte testi. Iga koodirida testitakse erinevalt traditsioonilisest testimisest.
• Nii traditsioonilise testimise kui ka TDD kombinatsioon toob kaasa süsteemi testimise kui süsteemi täiuslikkuse olulisuse.
• Agiilse modelleerimise (AM) puhul peaksite "katsetama eesmärgiga". Peaksite teadma, miks te midagi katsetate ja millisel tasemel seda tuleb testida.

Mis on aktsepteerimise TDD ja arendaja TDD

TDD on kahel tasemel

1. Aktsepteerimise TDD (ATDD): ATDD-ga kirjutate ühe aktsepteerimistesti. See test vastab spetsifikatsiooni nõuetele või süsteemi käitumisele. Pärast seda kirjutage selle vastuvõtutesti täitmiseks täpselt nii palju tootmis- / funktsionaalsuskoodi. Aktsepteerimistest keskendub süsteemi üldisele käitumisele. ATDD oli tuntud ka kui käitumispõhine areng (BDD).
2. Arendaja TDD: Arendaja TDD-ga kirjutate ühe arendaja testi ehk ühikutesti ja seejärel selle testi täitmiseks lihtsalt nii palju tootekoodi. Ühikutest keskendub süsteemi igale väiksemale funktsionaalsusele. Arendaja TDD-d nimetatakse lihtsalt TDD-ks.

   ATDD ja TDD peamine eesmärk on täpsustada teie lahenduse üksikasjalikud, käivitatavad nõuded õigeaegselt (JIT). JIT tähendab ainult nende nõuete arvestamist, mis on süsteemis vajalikud. Nii et suurendage efektiivsust.

TDD skaleerimine agiilse mudelipõhise arenduse (AMDD) kaudu

TDD on väga hea üksikasjalike spetsifikatsioonide ja valideerimise osas. See ei suuda läbi mõelda suuremaid küsimusi, nagu üldine disain, süsteemi kasutamine või kasutajaliides. AMDD tegeleb agiilse skaleerimise probleemidega, mida TDD ei lahenda.

Seega kasutas AMDD suuremate probleemide lahendamiseks.

AMDD elutsükkel.

Mudelipõhises arenduses (MDD) luuakse ulatuslikud mudelid enne lähtekoodi kirjutamist. Millistel omakorda on vilgas lähenemine?

Ülaloleval joonisel tähistab iga lahter arendustegevust.

Kujutamine on üks TDD protsessidest, mis ennustab / kujutleb teste, mis viiakse läbi projekti esimesel nädalal. Nägemise peamine eesmärk on tuvastada süsteemi ulatus ja süsteemi arhitektuur. Edukaks kujutlemiseks tehakse kõrgetasemelisi nõudeid ja arhitektuuri modelleerimist.

See on protsess, kus ei tehta tarkvara / süsteemi üksikasjalikku spetsifikatsiooni, vaid uuritakse tarkvara / süsteemi nõudeid, mis määratleb projekti üldise strateegia.

1. Kordus 0: ettekujutus

On kaks peamist alamaktiveerimist.

1. Esialgsete nõuete kavandamine.

   Kõrgetasemeliste nõuete ja süsteemi ulatuse kindlakstegemiseks võib kuluda mitu päeva. Põhitähelepanu on uurida kasutusmudelit, algdomeeni mudelit ja kasutajaliidese mudelit (UI).

2. Esialgne arhitektuuriline visioon.

   Samuti võtab süsteemi arhitektuuri tuvastamine mitu päeva. See võimaldab seada projekti tehnilisi suundi. Põhitähelepanu on uurida tehnoloogiadiagramme, kasutajaliidese voogu, domeenimudeleid ja muudatuste juhtumeid.

2. Iteratsiooni modelleerimine:

   Siin peab meeskond kavandama töö, mida tehakse iga iteratsiooni jaoks.

• Igas iteratsioonis kasutatakse kiiret protsessi, st iga iteratsiooni ajal lisatakse prioriteediga uus tööüksus.
• Arvestatakse esimest kõrgema prioriteediga tööd. Lisatud tööesemeid saab esemete järjekorrast ümber seada või eemaldada.
• Meeskond arutab, kuidas nad kavatsevad iga nõuet rakendada. Selleks kasutatakse modelleerimist.
• Modelleerimine ja kavandamine tehakse iga nõude jaoks, mida selle iteratsiooni jaoks rakendatakse.

3. Mudel tormis:

   Seda nimetatakse ka õigel ajal modelleerimiseks.

• Siin osaleb modelleerimise seanss 2/3 liikmega meeskonnast, kes arutavad küsimusi paberil või tahvlil.
• Üks meeskonnaliige palub teisel koos nendega modelleerida. See modelleerimisseanss võtab aega umbes 5–10 minutit. Kus meeskonnaliikmed tahvli / paberi jagamiseks kogunevad.
• Nad uurivad probleeme seni, kuni ei leia probleemi peamist põhjust. Täpselt õigel ajal, kui üks meeskonnaliige tuvastab probleemi, mille ta soovib lahendada, võtab ta teistelt meeskonnaliikmetelt kiiret abi.
• Seejärel uurivad teised rühmaliikmed seda teemat ja jätkavad siis kõik nagu varem. Seda nimetatakse ka stand-up modelleerimiseks või kliendi kvaliteediseanssideks.

4. Testpõhine areng (TDD).

• See edendab teie rakenduskoodi ja üksikasjaliku spetsifikatsiooni kinnitavat katsetamist.
• Nii vastuvõtutest (üksikasjalikud nõuded) kui ka arendaja testid (ühikutest) on TDD sisendiks.
• TDD muudab koodi lihtsamaks ja selgemaks. See võimaldab arendajal säilitada vähem dokumente.

5. Arvustused.

• See on vabatahtlik. See sisaldab koodide ülevaatusi ja mudelite ülevaatusi.
• Seda saab teha iga iteratsiooni või kogu projekti jaoks.
• See on hea võimalus projekti kohta tagasisidet anda.

Testpõhine areng (TDD) vs. Agile mudelipõhine arendus (AMDD)

TDD	AMDD
TDD lühendab programmeerimise tagasisidet	AMDD lühendab modelleerimise tagasisidet.
TDD on üksikasjalik spetsifikatsioon	AMDD töötab suuremate probleemide korral
TDD edendab kvaliteetsete koodide väljatöötamist	AMDD edendab kvaliteetset suhtlemist sidusrühmade ja arendajatega.
TDD räägib programmeerijatega	AMDD räägib ärianalüütiku, sidusrühmade ja andmespetsialistidega.
TDD pole visuaalselt orienteeritud	AMDD visuaalselt orienteeritud
TDD on piiratud tarkvaratöödega	AMDD on lai, sealhulgas sidusrühmad. See hõlmab tööd ühise arusaama nimel
Mõlemad toetavad evolutsioonilist arengut	--------------------------------------------

TDD näide

Siin näites määratleme klassi parooli. Selle klassi puhul püüame järgmisi tingimusi täita.

Parooli aktsepteerimise tingimus:

• Parool peaks olema vahemikus 5 kuni 10 tähemärki.

Kõigepealt kirjutame koodi, mis vastab kõigile ülaltoodud nõuetele.

Stsenaarium 1 : Testi käivitamiseks loome klassi PasswordValidator ();

Jookseme üle klassi TestPassword ();

Väljund läbitakse, nagu allpool näidatud;

Väljund :

Stsenaarium 2 : Siin näeme meetodis TestPasswordLength (), et pole vaja luua klassi PasswordValidator eksemplari. Eksemplar tähendab klassi objekti loomist, et viidata selle klassi liikmetele (muutujad / meetodid).

Me eemaldame koodist klassi PasswordValidator pv = new PasswordValidator (). Me võime meetodit isValid () kutsuda otse PasswordValidatori kaudu. IsValid ("Abc123") . (Vaata pilti allpool)

Nii et me Refactor (muutke koodi) nagu allpool:

Stsenaarium 3 : Pärast väljundi ümberehitamist kuvatakse nurjunud olek (vt allolevat pilti) selle põhjuseks on see, et oleme eksemplari eemaldanud. Seega pole viidet mittestaatilisele meetodile isValid ().

Nii et me peame seda meetodit muutma, lisades enne tõeväärtust sõna "staatiline", kuna avalik staatiline tõeväärtus on isValid (stringiparool). Katse läbimiseks ülaltoodud vea eemaldamiseks tehke klassi PasswordValidator () ümbertegemine.

Väljund:

Pärast testi PassValidator () muutmist kui katse käivitame, siis väljund läbitakse, nagu allpool näidatud.

TDD eelised

• Varajane veateade.

  Arendajad testivad oma koodi, kuid andmebaasimaailmas koosneb see sageli käsitsi testidest või ühekordsetest skriptidest. Kasutades TDD-d, koostate aja jooksul automatiseeritud testide komplekti, mida saate ise ja kõik muud arendajad oma suva järgi uuesti teha.

• Paremini kujundatud, puhtam ja laiendatavam kood.
  • See aitab mõista, kuidas koodi kasutatakse ja kuidas see teiste moodulitega suhtleb.
  • Selle tulemuseks on parem disainiotsus ja hooldatavam kood.
  • TDD võimaldab kirjutada väiksemat koodi, millel on üks vastutus, mitte mitme vastutusega monoliitseid protseduure. See muudab koodi mõistmise lihtsamaks.
  • Samuti sunnib TDD kasutaja nõudmistest lähtuvate testide läbimiseks kirjutama ainult tootmiskoodi.
• Usaldus refaktorile
  • Kui te refrakteerite koodi, võib koodis olla purunemisvõimalusi. Seega saate automaatsete testide komplekti abil need pausid enne vabastamist parandada. Õige hoiatus antakse, kui automatiseeritud testide kasutamisel leitakse pause.
  • TDD kasutamine peaks andma kiirema ja laiendatava koodi, milles oleks vähem vigu, mida saab värskendada minimaalsete riskidega.
• Hea meeskonnatööks

  Ühe meeskonnaliikme puudumisel saavad teised meeskonnaliikmed koodi hõlpsalt kätte võtta ja selle kallal töötada. See aitab ka teadmiste jagamist, muutes seeläbi meeskonna tõhusamaks.

• Hea arendajatele

  Ehkki arendajad peavad kulutama rohkem aega TDD testjuhtumite kirjutamisele, võtab silumine ja uute funktsioonide väljatöötamine palju vähem aega. Kirjutate puhtama ja vähem keeruka koodi.

Kokkuvõte:

• TDD tähistab testpõhist arendust. See on koodi muutmise protsess, et läbida varem loodud test.
• See paneb rohkem rõhku tootekoodile, mitte katsejuhtumi kujundamisele.
• Testpõhine arendus on koodi muutmise protsess, et läbida varem loodud test.
• Tarkvaratehnikas on see mõnikord tuntud kui "Test First Development".
• TDD sisaldab koodi ümbertegemist, st olemasoleva koodi teatud hulga koodide muutmist / lisamist, ilma et see mõjutaks koodi käitumist.
• TDD kasutamisel muutub kood selgemaks ja arusaadavaks.

Selle artikli autor on Kanchan Kulkarni