Kaj je testni razvoj (TDD)? Vadnica s primerom

Kazalo:

Anonim

Test Driven Development

Test Driven Development (TDD) je pristop za razvoj programske opreme, pri katerem se razvijejo testni primeri, da se določi in potrdi, kaj bo koda naredila. Preprosto povedano, najprej se ustvarijo in preizkusijo testni primeri za vsako funkcionalnost. Če test ne uspe, je nova koda napisana, da je test uspešno opravljen in je koda preprosta in brez napak.

Test-Driven Development se začne z načrtovanjem in razvojem testov za vsako majhno funkcionalnost aplikacije. TDD razvijalcem naroči, naj napišejo novo kodo le, če samodejni test ni uspel. S tem se izognemo podvajanju kode. Celotna oblika TDD je razvoj, ki temelji na testih.

Preprost koncept TDD je pisanje in popravljanje neuspelih testov pred pisanjem nove kode (pred razvojem). Tako se izognemo podvajanju kode, saj naenkrat napišemo majhno količino kode, da lahko opravimo teste. (Preskusi niso nič drugega kot zahtevani pogoji, ki jih moramo preizkusiti, da jih izpolnimo).

Test-Driven development je postopek razvijanja in izvajanja samodejnega preizkusa pred dejanskim razvojem aplikacije. Zato TDD včasih imenujejo tudi Test First Development.

V tej vadnici boste izvedeli več o-

  • Kako izvesti test TDD
  • TDD Vs. Tradicionalno testiranje
  • Kaj je TDD za sprejem in TDD za razvijalce
  • Skaliranje TDD s pomočjo Agile Model Driven Development (AMDD)
  • Test Driven Development (TDD) vs. Agile Model Driven Development (AMDD)
  • Primer TDD
  • Prednosti TDD

Kako izvesti test TDD

Naslednji koraki določajo, kako izvesti test TDD,

  1. Dodajte test.
  2. Zaženite vse teste in preverite, ali kateri nov test ne uspe.
  3. Napišite nekaj kode.
  4. Zaženite teste in kodo Refactor.
  5. Ponovite.

Cikel TDD definira

  1. Napišite test
  2. Naj teče.
  3. Spremenite kodo, da bo prava, npr. Refactor.
  4. Postopek ponovite.

Nekaj ​​pojasnil o TDD:

  • TDD ne gre niti za "testiranje" niti za "oblikovanje".
  • TDD ne pomeni, da "napišete nekaj testov, nato zgradite sistem, ki bo teste uspešno opravil.
  • TDD ne pomeni "opravite veliko testiranja."

TDD Vs. Tradicionalno testiranje

Pristop TDD je predvsem tehnika specifikacije. Zagotavlja, da je vaša izvorna koda temeljito preizkušena na potrditveni ravni.

  • Pri tradicionalnem testiranju uspešen test odkrije eno ali več napak. Enako je kot TDD. Ko test ne uspe, ste napredovali, ker veste, da morate težavo odpraviti.
  • TDD zagotavlja, da vaš sistem dejansko izpolnjuje zanje določene zahteve. Pomaga vam zgraditi zaupanje v vaš sistem.
  • V TDD je večji poudarek na proizvodni kodi, ki preverja, ali bo testiranje delovalo pravilno. Pri tradicionalnem testiranju je večji poudarek na zasnovi testnih primerov. Ali bo test pokazal pravilno / nepravilno izvajanje aplikacije za izpolnitev zahtev.
  • V TDD dosežete 100-odstotni test pokritosti. Vsaka vrstica kode je testirana, za razliko od tradicionalnega testiranja.
  • Kombinacija tradicionalnega testiranja in TDD vodi k pomembnosti testiranja sistema in ne do popolnosti sistema.
  • V agilnem modeliranju (AM) bi morali "testirati z namenom". Morali bi vedeti, zakaj nekaj preizkušate in kakšno raven je treba preizkusiti.

Kaj je TDD za sprejem in TDD za razvijalce

Obstajata dve ravni TDD

  1. Sprejemni TDD (ATDD): Z ATDD napišete en sam sprejemni test. Ta preskus izpolnjuje zahteve iz specifikacije ali izpolnjuje obnašanje sistema. Po tem napišite ravno toliko produkcijske / funkcionalne kode, da boste lahko opravili ta sprejemni test. Sprejemni test se osredotoča na splošno vedenje sistema. ATDD je bil znan tudi pod imenom Behavioral Driven Development (BDD).
  2. TDD za razvijalce: Z TDD za razvijalce napišete en test za razvijalce, tj. Test enote in nato ravno toliko produkcijske kode, da ga lahko opravite. Preizkus enote se osredotoča na vsako majhno funkcionalnost sistema. TDD za razvijalce preprosto imenujemo TDD.

    Glavni cilj ATDD in TDD je določiti podrobne in izvedljive zahteve za vašo rešitev na točno določen čas (JIT). JIT pomeni upoštevanje le tistih zahtev, ki so potrebne v sistemu. Torej povečajte učinkovitost.

Skaliranje TDD s pomočjo Agile Model Driven Development (AMDD)

TDD je zelo dober pri natančnih specifikacijah in validaciji. Ne razmišlja pri večjih vprašanjih, kot so splošna zasnova, uporaba sistema ali uporabniški vmesnik. AMDD se ukvarja s težavami pri skaliranju Agile, ki jih TDD ne.

Tako se je AMDD uporabljal za večje težave.

Življenjski cikel AMDD.

V Model-driven Development (MDD) pred izdelavo izvorne kode nastanejo obsežni modeli. Kateri pa imajo prožen pristop?

Na zgornji sliki vsako polje predstavlja razvojno dejavnost.

Predvidevanje je eden od TDD postopkov napovedovanja / predstavljanja testov, ki se bodo izvajali v prvem tednu projekta. Glavni cilj predvidevanja je opredeliti obseg sistema in arhitekturo sistema. Za uspešno načrtovanje se izvajajo zahteve na visoki ravni in modeliranje arhitekture.

To je postopek, pri katerem ni narejena podrobna specifikacija programske opreme / sistema, temveč raziskovanje zahtev programske opreme / sistema, ki opredeljuje splošno strategijo projekta.

  1. Ponovitev 0: Predstavljanje

Obstajata dve glavni podaktivi.

  1. Predvidevanje začetnih zahtev.

    Ugotavljanje zahtev in obsega sistema na visoki ravni lahko traja več dni. Glavni poudarek je raziskati model uporabe, model začetne domene in model uporabniškega vmesnika (UI).

  2. Začetno arhitekturno predvidevanje.

    Nekaj ​​dni traja tudi določitev arhitekture sistema. Omogoča določanje tehničnih navodil za projekt. Glavni poudarek je na raziskovanju tehnoloških diagramov, pretoka uporabniškega vmesnika (UI), domenskih modelov in sprememb primerov.

  1. Iteracijsko modeliranje:

    Tu mora ekipa načrtovati delo, ki bo opravljeno za vsako ponovitev.

  • Za vsako ponovitev se uporablja gibčen postopek, tj. Med vsako ponovitvijo bo nova delovna postavka dodana s prednostjo.
  • Upoštevana bodo prva dela z višjo prednostjo. Dodane delovne predmete lahko kadar koli spremenite s prednostnimi nalogami ali jih odstranite iz sklada.
  • Skupina razpravlja o tem, kako bo uresničila vsako zahtevo. V ta namen se uporablja modeliranje.
  • Analiza in načrtovanje modeliranja se izvede za vsako zahtevo, ki jo bomo izvedli za to ponovitev.
  1. Model vihar:

    To je znano tudi kot modeliranje ravno v času.

  • V tej seji modeliranja sodeluje skupina 2/3 članov, ki razpravljajo o vprašanjih na papirju ali tabli.
  • En član ekipe bo prosil drugega, naj se z njimi modelira. Ta seja modeliranja bo trajala približno 5 do 10 minut. Tam, kjer se člani ekipe zberejo, da si delijo tablo / papir.
  • Težave raziskujejo, dokler ne najdejo glavnega vzroka težave. Če bo član ekipe pravočasno ugotovil težavo, ki jo želi rešiti, bo hitro sprejel pomoč drugih članov ekipe.
  • Drugi člani skupine nato preučijo težavo in nato vsi nadaljujejo po starem. Imenuje se tudi kot stand-up modeliranje ali seje QA za stranke.
  1. Test Driven Development (TDD).
  • Spodbuja potrditveno testiranje vaše prijavne kode in podrobne specifikacije.
  • Tako test sprejemljivosti (podrobne zahteve) kot preizkus razvijalca (test enote) sta vhodna podatka za TDD.
  • TDD naredi kodo enostavnejšo in jasnejšo. Razvijalcu omogoča, da vzdržuje manj dokumentacije.
  1. Ocene.
  • To ni obvezno. Vključuje preglede kod in preglede modelov.
  • To lahko storite za vsako ponovitev ali za celoten projekt.
  • To je dobra možnost za povratne informacije o projektu.

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

TDD AMDD
  • TDD skrajša programsko povratno zanko
  • AMDD skrajša povratno zanko za modeliranje.
  • TDD je podrobna specifikacija
  • AMDD deluje za večje težave
  • TDD spodbuja razvoj visokokakovostne kode
  • AMDD spodbuja kakovostno komunikacijo z deležniki in razvijalci.
  • TDD govori s programerji
  • AMDD se pogovarja s poslovnimi analitiki, deležniki in strokovnjaki za obdelavo podatkov.
  • TDD ne-vizualno usmerjen
  • AMDD vizualno usmerjen
  • TDD ima omejen obseg del programske opreme
  • AMDD ima širok obseg, vključno z zainteresiranimi stranmi. Vključuje prizadevanja za skupno razumevanje
  • Oba podpirata evolucijski razvoj
 --------------------------------------------

Primer TDD

V tem primeru bomo opredelili geslo za razred. Za ta razred bomo poskušali izpolnjevati naslednje pogoje.

Pogoj za sprejem gesla:

  • Geslo mora biti med 5 in 10 znaki.

Najprej napišemo kodo, ki izpolnjuje vse zgoraj navedene zahteve.

1. scenarij : Za zagon testa izdelamo razred PasswordValidator ();

Zagnali bomo nad razredom TestPassword ();

Izhod je MENJEN, kot je prikazano spodaj;

Izhod :

Scenarij 2 : Tu lahko vidimo v metodi TestPasswordLength (), da ni treba ustvariti primerka razreda PasswordValidator. Primerek pomeni ustvarjanje predmeta razreda za napotitev članov (spremenljivk / metod) tega razreda.

Iz kode bomo odstranili razred PasswordValidator pv = new PasswordValidator (). Metodo isValid () lahko pokličemo neposredno z PasswordValidator. IsValid ("Abc123") . (Glej sliko spodaj)

Torej Refactor (spremenimo kodo) spodaj:

Scenarij 3 : Po refaktoringu izhoda pokaže neuspešno stanje (glej sliko spodaj), to je zato, ker smo primerek odstranili. Torej ni sklicevanja na nestatično metodo isValid ().

Torej moramo to metodo spremeniti z dodajanjem "statične" besede pred logično vrednostjo kot javno statično logično isValid (niz gesla). Refaktoriranje razreda PasswordValidator () za odstranitev zgornje napake za uspešno izvedbo preizkusa.

Izhod:

Po izvedbi sprememb v razredu PassValidator (), če izvedemo test, bo izhod PASSED, kot je prikazano spodaj.

Prednosti TDD

  • Zgodnje obvestilo o napakah.

    Razvijalci preizkušajo svojo kodo, toda v svetu baz podatkov to pogosto sestavljajo ročni testi ali enkratni skripti. Z uporabo TDD sčasoma ustvarite nabor avtomatiziranih testov, ki jih lahko vi in ​​kateri koli drugi razvijalec ponovite po želji.

  • Bolje oblikovana, čistejša in razširljivejša koda.
    • Pomaga razumeti, kako se bo koda uporabljala in kako bo vplivala na druge module.
    • Rezultat je boljša oblikovalska odločitev in bolj vzdržna koda.
    • TDD omogoča pisanje manjše kode z eno odgovornostjo in ne monolitnih postopkov z več odgovornostmi. Zaradi tega je koda enostavnejša za razumevanje.
    • TDD tudi sili, da piše samo produkcijsko kodo, da opravi teste na podlagi uporabniških zahtev.
  • Zaupanje Refaktorju
    • Če predelate kodo, lahko pride do prekinitev kode. Z naborom avtomatiziranih testov lahko te popravke popravite pred izdajo. Ustrezno opozorilo bo dano, če se pri samodejnih testih najdejo odmori.
    • Uporaba TDD bi morala povzročiti hitrejšo, razširljivejšo kodo z manj napakami, ki jih je mogoče posodobiti z minimalnimi tveganji.
  • Dobro za timsko delo

    V odsotnosti člana ekipe lahko drugi člani ekipe enostavno prevzamejo kodo in jo obdelajo. Pomaga tudi pri izmenjavi znanja, s čimer je ekipa na splošno učinkovitejša.

  • Dobro za razvijalce

    Čeprav morajo razvijalci porabiti več časa za pisanje testnih primerov TDD, traja veliko manj časa za odpravljanje napak in razvoj novih funkcij. Napisali boste čistejšo, manj zapleteno kodo.

Povzetek:

  • TDD pomeni razvoj, ki ga vodi test. Gre za postopek spreminjanja kode, da se opravi predhodno načrtovan test.
  • Bolj poudarja proizvodno kodo in ne zasnovo testnih primerov.
  • Razvoj, ki temelji na preskusu, je postopek spreminjanja kode, da se opravi preizkus, ki je bil predhodno zasnovan.
  • V programskem inženirstvu je včasih znano tudi kot "Test First Development".
  • TDD vključuje refaktoring kode, tj. Spreminjanje / dodajanje določene količine kode obstoječi kodi, ne da bi to vplivalo na obnašanje kode.
  • Pri uporabi TDD koda postane jasnejša in enostavnejša za razumevanje.

Ta članek prispeva Kanchan Kulkarni