Što je test pokretani razvoj (TDD)? Vodič s primjerom

Sadržaj:

Anonim

Test Driven Development

Test Driven Development (TDD) pristup je razvoju softvera u kojem se razvijaju test slučajevi kako bi se specificiralo i potvrdilo što će kôd raditi. Jednostavno rečeno, ispitni slučajevi za svaku funkcionalnost se prvo kreiraju i testiraju, a ako test ne uspije, novi kôd je napisan kako bi se test prošao i učinio kôd jednostavnim i bez grešaka.

Test-Driven Development započinje s dizajniranjem i razvojem testova za svaku manju funkcionalnost aplikacije. TDD nalaže programerima da napišu novi kod samo ako automatsko testiranje nije uspjelo. Time se izbjegava dupliciranje koda. Puni oblik TDD-a je razvoj temeljen na testovima.

Jednostavni koncept TDD-a je pisanje i ispravljanje neuspjelih testova prije pisanja novog koda (prije razvoja). To pomaže u izbjegavanju dupliciranja koda jer istovremeno pišemo malu količinu koda kako bismo prošli testove. (Ispitivanja nisu ništa drugo do uvjeti koje moramo testirati da bismo ih ispunili).

Test-Driven Development proces je razvoja i pokretanja automatiziranog testa prije stvarnog razvoja aplikacije. Stoga se TDD ponekad naziva i Test First Development.

U ovom vodiču naučit ćete više o-

  • Kako izvesti TDD test
  • TDD vs. Tradicionalno testiranje
  • Što je TDD za prihvaćanje i TDD za razvojne programere
  • Skaliranje TDD-a putem agilnog razvoja vođenog modelom (AMDD)
  • Test Driven Development (TDD) vs. Agile Model Driven Development (AMDD)
  • Primjer TDD-a
  • Prednosti TDD-a

Kako izvesti TDD test

Sljedeći koraci definiraju kako se izvodi TDD test,

  1. Dodajte test.
  2. Pokrenite sva ispitivanja i provjerite da li bilo koji novi test ne uspije.
  3. Napišite neki kod.
  4. Pokrenite testove i Refactor kôd.
  5. Ponoviti.

TDD ciklus definira

  1. Napišite test
  2. Neka trči.
  3. Promijenite kôd kako bi bio ispravan, tj. Refactor.
  4. Ponovite postupak.

Nekoliko pojašnjenja o TDD-u:

  • TDD nije niti "Testiranje" niti "Dizajn".
  • TDD ne znači "napisati neke testove, a zatim izgraditi sustav koji prolazi testove.
  • TDD ne znači "puno testirati".

TDD vs. Tradicionalno testiranje

TDD pristup je prvenstveno tehnika specifikacije. Osigurava da se vaš izvorni kod temeljito testira na potvrdnoj razini.

  • Tradicionalnim ispitivanjem uspješan test pronalazi jednu ili više mana. To je isto kao TDD. Kad test ne uspije, napredovali ste jer znate da morate riješiti problem.
  • TDD osigurava da vaš sustav stvarno ispunjava zahtjeve koji su za njega definirani. Pomaže u izgradnji vašeg povjerenja u vaš sustav.
  • U TDD-u je veći fokus na proizvodnom kodu koji provjerava hoće li testiranje raditi ispravno. U tradicionalnom testiranju veći je fokus na dizajnu test kutija. Hoće li test pokazati ispravno / nepravilno izvršavanje aplikacije kako bi se ispunili zahtjevi.
  • U TDD-u postižete test pokrivenosti od 100%. Testira se svaki pojedini redak koda, za razliku od tradicionalnog testiranja.
  • Kombinacija tradicionalnog testiranja i TDD-a dovodi do važnosti testiranja sustava, a ne do savršenstva sustava.
  • U agilnom modeliranju (AM) trebali biste "testirati sa svrhom". Trebali biste znati zašto nešto testirate i koji nivo treba testirati.

Što je TDD za prihvaćanje i TDD za razvojne programere

Postoje dvije razine TDD-a

  1. TDD prihvaćanja (ATDD): Uz ATDD pišete jedan test prihvaćanja. Ovo ispitivanje ispunjava zahtjev specifikacije ili zadovoljava ponašanje sustava. Nakon toga napišite tek toliko produkcijskog / funkcionalnog koda da ispunite taj test prihvaćanja. Test prihvaćanja usredotočen je na cjelokupno ponašanje sustava. ATDD je također bio poznat pod nazivom Behavioral Driven Development (BDD).
  2. TDD za razvojne programere: Uz TDD za razvojne programere pišete jedan test za razvojne programere, tj. Jedinični test, a zatim tek toliko proizvodnog koda da ispunite taj test. Jedinstveni test usredotočen je na svaku malu funkcionalnost sustava. TDD programera jednostavno se naziva TDD.

    Glavni cilj ATDD-a i TDD-a je odrediti detaljne, izvršne zahtjeve za vaše rješenje na osnovi JIT-a. JIT znači uzimati u obzir samo one zahtjeve koji su potrebni u sustavu. Pa povećajte učinkovitost.

Skaliranje TDD-a putem agilnog razvoja vođenog modelom (AMDD)

TDD je vrlo dobar u detaljnim specifikacijama i provjeri valjanosti. Ne uspijeva razmišljati o većim problemima kao što su cjelokupni dizajn, uporaba sustava ili korisničko sučelje. AMDD rješava probleme agilnog skaliranja koje TDD ne.

Stoga se AMDD koristi za veće probleme.

Životni ciklus AMDD-a.

U Razvoju vođenom modelom (MDD) stvaraju se opsežni modeli prije pisanja izvornog koda. Koji pak imaju agilni pristup?

Na gornjoj slici svaki okvir predstavlja razvojnu aktivnost.

Predviđanje je jedan od TDD procesa predviđanja / zamišljanja testova koji će se izvoditi tijekom prvog tjedna projekta. Glavni cilj predviđanja je identificirati opseg sustava i arhitekturu sustava. Zahtjevi na visokoj razini i modeliranje arhitekture rade se za uspješno predviđanje.

To je postupak u kojem se ne radi detaljna specifikacija softvera / sustava, već istraživanje zahtjeva softvera / sustava koji definira cjelokupnu strategiju projekta.

  1. Ponavljanje 0: Predviđanje

Dvije su glavne podaktive.

  1. Predviđanje početnih zahtjeva.

    Utvrđivanje zahtjeva na visokoj razini i opsega sustava može potrajati nekoliko dana. Glavni fokus je istražiti model upotrebe, model početne domene i model korisničkog sučelja (UI).

  2. Početno arhitektonsko predviđanje.

    Potrebno je i nekoliko dana da se identificira arhitektura sustava. Omogućuje postavljanje tehničkih uputa za projekt. Glavni fokus je istraživanje tehnoloških dijagrama, protoka korisničkog sučelja (UI), modela domene i promjena slučajeva.

  1. Iteracijsko modeliranje:

    Ovdje tim mora planirati posao koji će se obaviti za svaku iteraciju.

  • Agile postupak koristi se za svaku iteraciju, tj. Tijekom svake iteracije novi radni predmet bit će dodan s prioritetom.
  • Bit će uzeti u obzir prvi veći rad s prioritetima. Dodani radni predmeti mogu se u bilo kojem trenutku izmijeniti iz prioriteta ili ukloniti iz niza predmeta.
  • Tim raspravlja o tome kako će provesti svaki zahtjev. U tu svrhu koristi se modeliranje.
  • Analiza i dizajn modeliranja vrši se za svaki zahtjev koji će se primijeniti za tu iteraciju.
  1. Model oluje:

    Ovo je također poznato kao Model u vrijeme.

  • Ovdje sesija modeliranja uključuje tim od 2/3 člana koji raspravljaju o problemima na papiru ili ploči.
  • Jedan član tima zamolit će drugog da se modelira s njima. Ova sesija modeliranja trajat će otprilike 5 do 10 minuta. Gdje se članovi tima okupljaju kako bi dijelili ploču / papir.
  • Istražuju probleme dok ne pronađu glavni uzrok problema. Baš na vrijeme, ako jedan član tima identificira problem koji želi riješiti, potražit će brzu pomoć ostalih članova tima.
  • Ostali članovi grupe zatim istražuju problem i tada svi nastavljaju po starom. Također se naziva i stand-up modeliranje ili QA sesije kupca.
  1. Test Driven Development (TDD).
  • Promovira potvrdno testiranje vašeg prijavnog koda i detaljne specifikacije.
  • I test prihvatljivosti (detaljni zahtjevi) i razvojni testovi (jedinični test) su ulazni podaci za TDD.
  • TDD kôd čini jednostavnijim i jasnijim. Omogućuje programeru da zadrži manje dokumentacije.
  1. Recenzije.
  • Ovo nije obavezno. Uključuje inspekcije koda i preglede modela.
  • To se može učiniti za svaku iteraciju ili za cijeli projekt.
  • Ovo je dobra opcija za povratne informacije o projektu.

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

TDD AMDD
  • TDD skraćuje programsku povratnu spregu
  • AMDD skraćuje petlju povratnih informacija o modeliranju.
  • TDD je detaljna specifikacija
  • AMDD radi na većim problemima
  • TDD promiče razvoj visokokvalitetnog koda
  • AMDD promiče visokokvalitetnu komunikaciju sa dionicima i programerima.
  • TDD razgovara s programerima
  • AMDD razgovara s poslovnim analitičarima, dionicima i stručnjacima za obradu podataka.
  • TDD nevizuelno orijentiran
  • AMDD vizualno orijentiran
  • TDD ima ograničen opseg na softverske radove
  • AMDD ima širok opseg, uključujući dionike. Uključuje rad na zajedničkom razumijevanju
  • Oboje podržavaju evolucijski razvoj
 --------------------------------------------

Primjer TDD-a

Ovdje ćemo u ovom primjeru definirati lozinku klase. Za ovu nastavu pokušat ćemo zadovoljiti sljedeće uvjete.

Uvjet za prihvaćanje lozinke:

  • Lozinka treba imati između 5 i 10 znakova.

Prvo napišemo kod koji ispunjava sve gore navedene zahtjeve.

Scenarij 1 : Da bismo pokrenuli test, kreiramo klasu PasswordValidator ();

Pokrenut ćemo iznad klase TestPassword ();

Izlaz je PROLAZEN kao što je prikazano dolje;

Izlaz :

Scenarij 2 : Ovdje možemo vidjeti u metodi TestPasswordLength () nema potrebe za stvaranjem instance klase PasswordValidator. Instanca znači stvaranje objekta klase za upućivanje članova (varijabli / metoda) te klase.

Iz koda ćemo ukloniti klasu PasswordValidator pv = new PasswordValidator (). Metodu isValid () možemo pozvati izravno pomoću PasswordValidator. IsValid ("Abc123") . (Pogledajte sliku dolje)

Dakle, mi Refaktor (mijenjamo kod) kao dolje:

Scenarij 3 : Nakon refaktoriranja izlaza prikazuje se neuspjeli status (vidi sliku dolje), to je zato što smo uklonili instancu. Dakle, nema reference na nestatičnu metodu isValid ().

Stoga moramo promijeniti ovu metodu dodavanjem riječi "static" prije Boolean-a kao javnog statičkog boolean-a isValid (lozinka niza). Refaktoriranje klase PasswordValidator () za uklanjanje gornje pogreške za prolazak testa.

Izlaz:

Nakon izvršenih promjena u klasi PassValidator (), ako pokrenemo test, izlaz će biti PROLAZEN kao što je prikazano dolje.

Prednosti TDD-a

  • Rano obavještavanje o programskoj pogrešci.

    Programeri testiraju svoj kod, ali u svijetu baza podataka to se često sastoji od ručnih testova ili jednokratnih skripti. Korištenjem TDD-a s vremenom izrađujete niz automatiziranih testova koje vi i bilo koji drugi programer možete izvoditi po svojoj volji.

  • Bolje dizajniran, čišći i proširiviji kod.
    • Pomaže razumjeti kako će se kôd koristiti i kako komunicira s drugim modulima.
    • Rezultat je bolja odluka o dizajnu i održiviji kod.
    • TDD omogućuje pisanje manjeg koda s jednom odgovornošću, a ne monolitnim postupcima s višestrukom odgovornošću. To kôd čini jednostavnijim za razumijevanje.
    • TDD također prisiljava pisanje samo proizvodnog koda da bi prošao testove na temelju korisničkih zahtjeva.
  • Povjerenje Refaktoru
    • Ako refaktorirate kôd, mogu postojati mogućnosti prekida u kodu. Dakle, imajući niz automatiziranih testova možete popraviti te pauze prije puštanja. Ispravno upozorenje dat će se ako se pronađu prekidi kada se koriste automatizirani testovi.
    • Korištenje TDD-a trebalo bi rezultirati bržim, proširivim kodom s manje bugova koji se mogu ažurirati uz minimalne rizike.
  • Dobro za timski rad

    U odsutnosti člana tima, drugi članovi tima mogu lako podići i raditi na šifri. Također pomaže u razmjeni znanja, čineći tim sveukupno učinkovitijim.

  • Dobro za programere

    Iako programeri moraju trošiti više vremena na pisanje TDD test slučajeva, potrebno je puno manje vremena za uklanjanje pogrešaka i razvoj novih značajki. Napisat ćete čistiji, manje komplicirani kod.

Sažetak:

  • TDD je skraćenica od Test-driven development. To je postupak izmjene koda kako bi se prošao test koji je prethodno dizajniran.
  • Više naglašava proizvodni kôd, a ne dizajn testnih slučajeva.
  • Razvoj vođen testom postupak je izmjene koda radi polaganja testa koji je prethodno dizajniran.
  • U softverskom inženjerstvu ponekad je poznato i kao "Test First Development".
  • TDD uključuje refaktoriranje koda, tj. Promjenu / dodavanje neke količine koda postojećem kodu bez utjecaja na ponašanje koda.
  • TDD kada se koristi, kôd postaje jasniji i jednostavniji za razumijevanje.

Ovaj članak je napisao Kanchan Kulkarni