Mis on testipõhine arendus (TDD)? Näide

Autor: Thomas Hamilton Thomas Hamilton
Hours Ajakohastatud

Mis on testipõhine arendus (TDD)?

Testipõhine arendus (TDD) on tarkvaraarenduse lähenemisviis, mille puhul töötatakse välja testjuhtumid, et täpsustada ja kinnitada, mida kood teeb. Lihtsamalt öeldes luuakse ja testitakse esmalt iga funktsionaalsuse testjuhtumid ning kui test ebaõnnestub, siis kirjutatakse uus kood, et testi läbida ja kood oleks lihtne ja veavaba.

Testipõhine arendus algab testide kavandamisest ja arendamisest rakenduse iga väiksema funktsiooni jaoks. TDD raamistik juhendab arendajaid uut koodi kirjutama ainult siis, kui automatiseeritud test on ebaõnnestunud. See väldib koodi dubleerimist. TDD täisvorm on testipõhine arendus.

Testipõhine areng

TDD lihtne kontseptsioon on kirjutada ja parandada ebaõnnestunud testid enne uue koodi kirjutamist (enne arendust). See aitab vältida koodi dubleerimist, kuna kirjutame testide läbimiseks korraga väikese koguse koodi. (Testid pole muud kui nõutavad tingimused, mida peame nende täitmiseks testima).

Testipõhine arendus on automatiseeritud testi arendamise ja käivitamise protsess enne rakenduse tegelikku arendamist. Seetõttu nimetatakse TDD-d mõnikord ka kui Testige esimest arengut.

Kuidas teha TDD testi

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

  1. Lisa test.
  2. Käivitage kõik testid ja vaadake, kas mõni uus test ebaõnnestub.
  3. Kirjutage mingi kood.
  4. Käivitage testid ja Refaktori kood.
  5. Korda.
Tehke TDD test
Testipõhise arenduse viis sammu

TDD tsükkel määratleb

  1. Kirjutage test
  2. Pane jooksma.
  3. Muutke koodi, et see oleks õige, st Refaktor.
  4. Korda protsessi.

Mõned selgitused TDD kohta:

  • TDD lähenemine ei puuduta "testimist" ega "disaini".
  • TDD ei tähenda "kirjutage mõned testid ja seejärel ehitage süsteem, mis läbib testid.
  • TDD ei tähenda "tehke palju testimist".

TDD vs. Traditsiooniline testimine

Allpool on toodud peamine erinevus testipõhise arenduse ja traditsioonilise testimise vahel.

TDD lähenemisviis on peamiselt spetsifikatsioonitehnika. See tagab, et teie lähtekoodi testitakse põhjalikult kinnitaval tasemel.

  • Traditsioonilise testimise korral leiab edukas test ühe või mitu defekti. See on sama, mis TDD. Kui test ebaõnnestub, olete teinud edusamme, sest teate, et peate probleemi lahendama.
  • TDD tagab, et teie süsteem vastab tegelikult sellele määratud nõuetele. See aitab suurendada teie usaldust oma süsteemi suhtes.
  • TDD-s keskendutakse rohkem tootmiskoodile, mis kontrollib, kas testimine töötab korralikult. Traditsioonilises testimises keskendutakse rohkem testjuhtumite kavandamisele. Kas test näitab rakenduse õiget/ebaõiget täitmist nõuete täitmiseks.
  • TDD-s saavutate 100% katvuse testi. Erinevalt traditsioonilisest testimisest testitakse iga koodirida.
  • Nii traditsioonilise testimise kui ka TDD kombinatsioon toob kaasa süsteemi testimise olulisuse, mitte süsteemi täiuslikkuse.
  • In Agiilne modelleerimine (AM), peaksite katsetama eesmärgiga. Peaksite teadma, miks te midagi testite ja millisel tasemel seda testida tuleb.

SEOTUD ARTIKLID

Mis on aktsepteerimise TDD ja arendaja TDD

TDD-l on kaks taset

  1. Aktsepteeritav TDD (ATDD): ATDD-ga kirjutate ühe vastuvõtutesti. See test vastab spetsifikatsiooni nõuetele või süsteemi käitumisele. Pärast seda kirjutage täpselt nii palju tootmis-/funktsionaalsuskoodi, et see vastuvõtmistesti täita. Vastuvõtutest keskendub süsteemi üldisele käitumisele. ATDD oli tuntud ka kui Käitumuslik areng (BDD).
  2. Arendaja TDD: Developer TDD-ga kirjutate ühe arendaja testi, st ühikutesti, ja seejärel täpselt selle testi täitmiseks vajaliku tootmiskoodi. Seadmetest keskendub süsteemi igale väiksemale funktsioonile. Arendaja TDD-d nimetatakse lihtsalt kui TDD.ATDD ja TDD põhieesmärk on täpsustada teie lahendusele üksikasjalikud käivitatavad nõuded just-in time (JIT) alusel. JIT tähendab ainult nende nõuete arvestamist, mida süsteemis vaja on. Seega suurendage tõhusust.

Aktsepteeritav TDD ja arendaja TDD

TDD skaleerimine Agile Model Driven Development (AMDD) kaudu

TDD on üksikasjaliku spetsifikatsiooni ja valideerimise osas väga hea. See ei suuda läbi mõelda suuremaid probleeme, nagu üldine disain, süsteemi kasutamine või kasutajaliides. AMDD tegeleb Agile skaleerimise probleemidega, mida TDD ei tee.

Seega kasutatakse AMDD-d suuremate probleemide jaoks.

AMDD elutsükkel

AMDD elutsükkel

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

Ülaltoodud joonisel tähistab iga kast arendustegevust.

Nägemine on üks TDD-protsessidest, mille eesmärk on ennustada/kujutleda teste, mis viiakse läbi projekti esimesel nädalal. Mõjutamise peamine eesmärk on tuvastada süsteemi ulatus ja süsteemi arhitektuur. Edukaks ettekujutamiseks tehakse kõrgetasemelisi nõudeid ja arhitektuuri modelleerimist.

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

Iteratsioon 0: nägemine

Seal on kaks peamist alamaktiveerimist.

  1. Esialgsete nõuete kavandamine.Kõrgetasemeliste nõuete ja süsteemi ulatuse tuvastamiseks võib kuluda mitu päeva. Põhirõhk on kasutusmudeli, algdomeeni mudeli ja kasutajaliidese mudeli (UI) uurimisel.
  2. Esialgne Architektuurne ettekujutus. Samuti kulub süsteemi arhitektuuri tuvastamiseks mitu päeva. See võimaldab määrata projekti tehnilisi suundi. Põhirõhk on tehnoloogiadiagrammide, kasutajaliidese (UI) voo, domeenimudelite ja muutuste juhtumite uurimisel.

Iteratsiooni modelleerimine

Siin peab meeskond planeerima iga iteratsiooni jaoks tehtava töö.

  • Iga iteratsiooni puhul kasutatakse agiilset protsessi ehk iga iteratsiooni käigus lisatakse prioriteediga uus tööüksus.
  • Esimesena võetakse arvesse kõrgema prioriteediga tööd. Lisatud tööüksuste prioriteete võib igal ajal muuta või üksuste virnast eemaldada.
  • Meeskond arutab, kuidas nad kavatsevad iga nõuet rakendada. Selleks kasutatakse modelleerimist.
  • Modelleerimisanalüüs ja projekteerimine tehakse iga nõude jaoks, mida selle iteratsiooni jaoks rakendatakse.

Modellide tormamine

Seda tuntakse ka kui Just in time Modeling.

  • Siin osaleb modelleerimisseanss 2/3 liikmelist meeskonda, kes arutavad probleeme paberil või tahvlil.
  • Üks meeskonnaliige palub teisel endaga modelleerida. See modelleerimisseanss kestab umbes 5–10 minutit. Kuhu meeskonnaliikmed kogunevad, et jagada tahvlit/paberit.
  • Nad uurivad probleeme seni, kuni ei leia probleemi peamist põhjust. Õigel ajal, kui üks meeskonnaliige tuvastab probleemi, mida ta soovib lahendada, kasutab ta kiiret abi teistelt meeskonnaliikmetelt.
  • Teised rühmaliikmed uurivad seejärel probleemi ja kõik jätkavad nagu varem. Seda nimetatakse ka stand-up modelleerimiseks või kliendi kvaliteedi tagamise seanssideks.

Testipõhine arendus (TDD)

  • See soodustab teie rakenduse koodi ja üksikasjalike spetsifikatsioonide kinnitavat testimist.
  • Nii vastuvõtutest (üksikasjalikud nõuded) kui ka arendajatestid (ühikutest) on TDD sisenditeks.
  • TDD muudab koodi lihtsamaks ja selgemaks. See võimaldab arendajal säilitada vähem dokumentatsiooni.

Arvustused

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

Testipõhine arendus (TDD) vs. Agiilne mudelipõhine arendus (AMDD)

TDD AMDD
TDD lühendab programmeerimise tagasisideahelat AMDD lühendab modelleerimise tagasisideahelat.
TDD on üksikasjalik spetsifikatsioon AMDD töötab suuremate probleemide korral
TDD edendab kvaliteetse koodi väljatöötamist AMDD edendab kvaliteetset suhtlust sidusrühmade ja arendajatega.
TDD räägib programmeerijatega AMDD räägib Business Analyst, sidusrühmad ja andmespetsialistid.
TDD mittevisuaalselt orienteeritud AMDD visuaalselt orienteeritud
TDD-l on tarkvaratööde ulatus piiratud AMDD-l on lai ulatus, sealhulgas sidusrühmad. See hõlmab ühise arusaama saavutamist
Mõlemad toetavad evolutsioonilist arengut ---------------

TDD raamistikud

Siin on parimate testipõhise arenduse (TDD) raamistike loend

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

Õpime nüüd näite varal katsepõhist arendust.

TDD näide

Selles testipõhise arenduse näites määratleme klassi parooli. Selle klassi puhul püüame täita järgmisi tingimusi.

Parooli aktsepteerimise tingimus:

  • Parool peaks olema 5–10 tähemärgi pikkune.

Selles TDD näites kirjutame kõigepealt koodi, mis vastab kõigile ülaltoodud nõuetele.

TDD näide

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

TDD näide

Töötame klassi TestPassword ();

Väljund on LÄBISTUD, nagu allpool näidatud;

Väljund:

TDD näide

Stsenaarium 2: Siin näeme meetodi TestPasswordLength () puhul, et pole vaja luua klassi PasswordValidator eksemplari. Näide tähendab an objekt klassist, et viidata selle klassi liikmetele (muutujatele/meetoditele).

TDD näide

Eemaldame koodist klassi PasswordValidator pv = new PasswordValidator (). Võime helistada on kehtiv () meetodil otse Paroolivalidaator. IsValid (“Abc123”). (Vaata pilti allpool)

Refaktoreerime (muudame koodi) järgmiselt:

TDD näide

Stsenaarium 3: Pärast ümbertegemist näitab väljund ebaõnnestunud olekut (vt allolevat pilti), kuna oleme eksemplari eemaldanud. Seega puudub viide mittestaatilisele meetodile isValid ().

TDD näide

Seega peame seda meetodit muutma, lisades sõna „staatiline” enne Booleani kui avalik staatiline tõeväärtus isValid (stringi parool). Refactoring Class PasswordValidator () eemaldab ülaltoodud vea testi läbimiseks.

TDD näide

Väljund:

Pärast muudatuste tegemist klassis PassValidator () kui testi käivitame, siis väljund LÄBITATUD, nagu allpool näidatud.

TDD näide

TDD eelised

Tarkvaratehnika testipõhise arendamise peamised eelised on järgmised:

Varajane veateade.

  • Arendajad testivad oma koodi, kuid andmebaasimaailmas koosneb see sageli käsitsi testimisest või ühekordsetest skriptidest. TDD-d kasutades koostate aja jooksul automatiseeritud testide komplekti, mida teie ja iga teine ​​arendaja saate soovi korral uuesti käivitada.

Paremini kujundatud, puhtam ja rohkem laiendatav kood.

  • See aitab mõista, kuidas koodi kasutatakse ja kuidas see teiste moodulitega suhtleb.
  • Selle tulemuseks on parem disainiotsus ja paremini hooldatav kood.
  • TDD võimaldab kirjutada väiksemat koodi, millel on üks vastutus, mitte monoliitsed protseduurid, millel on mitu vastutust. See muudab koodi mõistmise lihtsamaks.
  • Samuti sunnib TDD kasutaja nõudmistel põhinevate testide läbimiseks kirjutama ainult tootmiskoodi.

Usaldus Refaktori vastu

  • Kui refaktoreerite koodi, võib koodis esineda katkestusi. Nii et automaattestide komplekti abil saate need katkestused enne vabastamist parandada. Kui automaattestide kasutamisel leitakse katkestusi, antakse nõuetekohane hoiatus.
  • TDD kasutamine peaks andma kiirema, laiendatavama koodi, milles on vähem vigu, mida saab minimaalse riskiga värskendada.

Hea meeskonnatööks

  • Ühegi meeskonnaliikme puudumisel saavad teised meeskonnaliikmed koodi hõlpsalt kätte saada ja selle kallal töötada. See aitab kaasa ka teadmiste jagamisele, muutes seeläbi meeskonna üldiselt tõhusamaks.

Hea arendajatele

  • Kuigi arendajad peavad kulutama rohkem aega TDD testjuhtumite kirjutamisele, kulub silumiseks ja uute funktsioonide väljatöötamiseks palju vähem aega. Kirjutate puhtama ja vähem keerulise koodi.

kokkuvõte

  • TDD tähistab testipõhist arendust.
  • TDD tähendus: see on koodi muutmise protsess, et läbida eelnevalt loodud test.
  • See paneb rohkem rõhku tootmiskoodile, mitte testjuhtumi disainile.
  • Testipõhine arendus on koodi muutmise protsess, et läbida eelnevalt loodud test.
  • In Tarkvaraarendus, Seda nimetatakse mõnikord "Testi esimene arendus."
  • TDD testimine hõlmab koodi ümberkujundamist, st teatud koguse koodi muutmist/lisamist olemasolevale koodile, ilma et see mõjutaks koodi käitumist.
  • TDD programmeerimisel muutub kood selgemaks ja hõlpsasti mõistetavaks.