Što je Test Driven Development (TDD)? Primjer

Što je Test Driven Development (TDD)?

Testom vođen razvoj (TDD) je pristup razvoju softvera u kojem se testni slučajevi razvijaju kako bi se odredilo i potvrdilo što će kod učiniti. Jednostavno rečeno, prvo se kreiraju i testiraju testni slučajevi za svaku funkcionalnost, a ako test ne uspije, piše se novi kod kako bi prošao test i učinio kod jednostavnim i bez grešaka.

Razvoj vođen testiranjem započinje dizajniranjem i razvojemping testovi za svaku malu funkcionalnost aplikacije. TDD okvir upućuje razvojne programere da pišu novi kod samo ako automatizirani test nije uspio. Time se izbjegava dupliciranje koda. Puni oblik TDD-a je Test-driven development (razvoj vođen testiranjem).

Jednostavan koncept TDD-a je napisati i ispraviti neuspjele testove prije pisanja novog koda (prije razvoja). To pomaže u izbjegavanju dupliciranja koda jer pišemo malu količinu koda odjednom kako bismo prošli testove. (Testovi nisu ništa drugo nego uvjeti zahtjeva koje trebamo testirati da bismo ih ispunili).

Razvoj vođen testiranjem je proces razvojaping i pokretanje automatiziranog testiranja prije stvarnog razvoja aplikacije. Stoga se TDD ponekad naziva i Testirajte prvi razvoj.

Kako izvesti TDD test

Sljedeći koraci definiraju kako izvršiti TDD test,

1. Dodajte test.
2. Pokrenite sve testove i pogledajte hoće li neki novi test biti neuspješan.
3. Napišite neki kod.
4. Pokrenite testove i refaktorirajte kod.
5. Ponoviti.

TDD ciklus definira

1. Napiši test
2. Pokreni ga.
3. Promijenite kod da bude ispravan, tj. Refactor.
4. Ponovite postupak.

Neka pojašnjenja o TDD-u:

• TDD pristup se ne odnosi ni na "testiranje" ni na "dizajn".
• TDD ne znači “napišite neke od testova, a zatim izgradite sustav koji prolazi testove.
• TDD ne znači "raditi puno testiranja".

TDD vs. Tradicionalno testiranje

Ispod je glavna razlika između razvoja vođenog testiranjem i tradicionalnog testiranja:

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

• Kod tradicionalnog testiranja, uspješan test otkriva jedan ili više nedostataka. Isto je kao TDD. Kada test ne uspije, napredovali ste jer znate da trebate riješiti problem.
• TDD osigurava da vaš sustav zaista ispunjava zahtjeve definirane za njega. 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 ispravno funkcionirati. U tradicionalnom testiranju veći je fokus na dizajnu testnog slučaja. Hoće li test pokazati pravilno/nepravilno izvršavanje aplikacije kako bi se ispunili zahtjevi.
• U TDD-u postižete 100% test pokrivenosti. Testira se svaka pojedinačna linija koda, za razliku od tradicionalnog testiranja.
• Kombinacija tradicionalnog testiranja i TDD-a dovodi do važnosti testiranja sustava, a ne savršenstva sustava.
• In Agilno modeliranje (AM), trebali biste "testirati sa svrhom". Trebali biste znati zašto nešto testirate i koju razinu treba testirati.

Što je TDD prihvaćanja i TDD programera

Postoje dvije razine TDD-a

1. TDD prihvaćanja (ATDD): Uz ATDD pišete jedan test prihvaćanja. Ovaj test ispunjava zahtjeve specifikacije ili zadovoljava ponašanje sustava. Nakon toga napišite dovoljno proizvodnog/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 kao Razvoj vođen ponašanjem (BDD).
2. TDD programera: Uz Developer TDD pišete jedan razvojni test, tj. jedinični test, a zatim dovoljno proizvodnog koda da ispunite taj test. Jedinični test fokusira se na svaku malu funkcionalnost sustava. Developer TDD jednostavno se zove as TDD.Glavni cilj ATDD-a i TDD-a je specificirati detaljne, izvršne zahtjeve za vaše rješenje na temelju pravovremenog rješenja (JIT). JIT znači uzeti u obzir samo one zahtjeve koji su potrebni u sustavu. Dakle, povećajte učinkovitost.

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

TDD je vrlo dobar u detaljnim specifikacijama i validaciji. Ne uspijeva promisliti o većim pitanjima kao što su cjelokupni dizajn, korištenje sustava ili korisničko sučelje. AMDD rješava probleme Agile skaliranja koje TDD ne rješava.

Stoga se AMDD koristi za veće probleme.

Životni ciklus AMDD-a

U razvoju vođenom modelom (MDD), opsežni modeli se stvaraju prije nego što se napiše izvorni kod. Koji pak imaju agilni pristup?

Na gornjoj slici svaki okvir predstavlja razvojnu aktivnost.

Zamišljanje je jedan od TDD procesa predviđanja/zamišljanja testova koji će se provoditi tijekom prvog tjedna projekta. Glavni cilj vizioniranja je identificirati opseg sustava i arhitekturu sustava. Zahtjevi visoke razine i modeliranje arhitekture rade se za uspješno vizioniranje.

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

Iteracija 0: Zamišljanje

Postoje dvije glavne podaktivacije.

1. Predviđanje početnih zahtjeva.Može potrajati nekoliko dana za utvrđivanje zahtjeva visoke razine i opsega sustava. Glavni fokus je na istraživanju modela upotrebe, modela početne domene i modela korisničkog sučelja (UI).
2. Početni Archiarhitektonsko predviđanje. Također je potrebno nekoliko dana da se identificira arhitektura sustava. Omogućuje postavljanje tehničkih smjernica za projekt. Glavni fokus je na istraživanju tehnoloških dijagrama, tijeka korisničkog sučelja (UI), modela domene i slučajeva promjene.

Iteracijsko modeliranje

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

• Agilni proces se koristi za svaku iteraciju, tj. tijekom svake iteracije, nova radna stavka će biti dodana sa prioritetom.
• U obzir će se uzeti prvi poslovi višeg prioriteta. Dodanim radnim stavkama može se promijeniti prioritet ili ukloniti sa hrpe stavki u bilo kojem trenutku.
• Tim raspravlja o tome kako će implementirati svaki zahtjev. U tu svrhu koristi se modeliranje.
• Analiza modeliranja i dizajn se rade za svaki zahtjev koji će se implementirati za tu iteraciju.

Model juriša

Ovo je također poznato kao pravovremeno modeliranje.

• Ovdje sesija modeliranja uključuje tim od 2/3 člana koji raspravlja o problemima na papiru ili ploči.
• Jedan član tima zamolit će drugog da modelira s njim. Ova sesija modeliranja trajat će otprilike 5 do 10 minuta. Gdje se članovi tima okupljaju kako bi dijelili ploču/papir.
• Oni istražuju probleme dok ne pronađu glavni uzrok problema. Upravo na vrijeme, ako jedan član tima identificira problem koji želi riješiti, tada će uzeti brzu pomoć ostalih članova tima.
• Ostali članovi grupe zatim istražuju problem, a zatim svi nastavljaju po starom. Također se naziva stand-up modeling ili QA sesije kupaca.

Testom vođen razvoj (TDD)

• Promiče potvrdno testiranje koda vaše aplikacije i detaljne specifikacije.
• Oba testa prihvaćanja (detaljni zahtjevi) i testovi programera (jedinični test) su ulazi za TDD.
• TDD čini kod jednostavnijim i jasnijim. Programeru omogućuje održavanje manje dokumentacije.

Reviews

• Ovo nije obavezno. Uključuje inspekcije kodova i preglede modela.
• To se može učiniti za svaku iteraciju ili za cijeli projekt.
• Ovo je dobra opcija za davanje povratnih informacija za projekt.

Testom vođen razvoj (TDD) vs. Razvoj vođen agilnim modelom (AMDD)

TDD	AMDD
TDD skraćuje povratnu petlju programiranja	AMDD skraćuje povratnu petlju modeliranja.
TDD je detaljna specifikacija	AMDD radi za veće probleme
TDD promiče razvoj visokokvalitetnog koda	AMDD promovira visokokvalitetnu komunikaciju sa dionicima i programerima.
TDD razgovara s programerima	AMDD razgovara s Poslovni analitičar, dionici i stručnjaci za podatke.
TDD nevizualno orijentiran	AMDD vizualno orijentiran
TDD ima ograničen opseg softverskih radova	AMDD ima širok opseg uključujući dionike. To uključuje rad na zajedničkom razumijevanju
Oba podržavaju evolucijski razvoj	---------------

TDD okviri

Ovdje je popis najboljih razvojnih okvira vođenih testiranjem (TDD).

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

Naučimo sada Test Driven Development na primjeru.

Primjer TDD-a

Ovdje u ovom primjeru razvoja vođenog testiranjem definirat ćemo lozinku klase. Za ovu klasu nastojat ćemo zadovoljiti sljedeće uvjete.

Uvjet za prihvaćanje lozinke:

• Lozinka bi trebala imati između 5 i 10 znakova.

Prvo u ovom TDD primjeru pišemo kod koji ispunjava sve gore navedene zahtjeve.

Scenarij 1: Za pokretanje testa kreiramo klasu PasswordValidator ();

Pokrenut ćemo iznad klase TestPassword ();

Izlaz je PASSED kao što je prikazano u nastavku;

Izlaz:

Scenarij 2: Ovdje možemo vidjeti u metodi TestPasswordLength () da nema potrebe za stvaranjem instance klase PasswordValidator. Instanca znači stvaranje objekt klase za upućivanje na članove (varijable/metode) te klase.

Uklonit ćemo klasu PasswordValidator pv = new PasswordValidator () iz koda. Možemo nazvati isValid () metoda izravno putem PasswordValidator. IsValid ("Abc123"). (Pogledajte sliku ispod)

Stoga vršimo refaktor (mijenjamo kod) kao što je prikazano u nastavku:

Scenarij 3: Nakon refaktoriranja izlaz pokazuje neuspjeli status (pogledajte sliku ispod) to je zato što smo uklonili instancu. Dakle, nema reference na nestatičku metodu isValid ().

Dakle, moramo promijeniti ovu metodu dodavanjem "statične" riječi prije Booleana kao javnog statičnog Booleana isValid (String lozinka). Refactoring Class PasswordValidator () za uklanjanje gornje pogreške za prolaz testa.

Izlaz:

Nakon unošenja promjena u klasu PassValidator (), ako pokrenemo test, izlaz će biti PROĐEN kao što je prikazano u nastavku.

Prednosti TDD-a

Slijede glavne prednosti testiranja vođenog razvoja u softverskom inženjerstvu:

Rana obavijest o bugovima.

• 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 gradite paket automatiziranih testova koje vi i bilo koji drugi programer možete ponovno pokrenuti po želji.

Bolje dizajniran, čišći i proširivi kod.

• Pomaže razumjeti kako će se kod koristiti i kako je u interakciji s drugim modulima.
• To rezultira boljom dizajnerskom odlukom i kodom koji se lakše održava.
• TDD omogućuje pisanje manjeg koda s jednom odgovornošću umjesto monolitnih procedura s višestrukim odgovornostima. To kod čini jednostavnijim za razumijevanje.
• TDD također prisiljava na pisanje samo proizvodnog koda kako bi prošao testove na temelju zahtjeva korisnika.

Povjerenje za refaktor

• Ako refaktorirate kod, mogu postojati mogućnosti prekida koda. Dakle, s nizom automatiziranih testova možete popraviti te kvarove prije izdavanja. Dobit će se odgovarajuće upozorenje ako se pronađu prekidi kada se koriste automatizirani testovi.
• Korištenje TDD-a trebalo bi rezultirati bržim, proširivijim kodom s manje grešaka koji se može ažurirati uz minimalne rizike.

Dobro za timski rad

• U nedostatku bilo kojeg člana tima, drugi članovi tima mogu lako preuzeti i raditi na kodu. Također pomaže u dijeljenju znanja, čineći tim sveukupno učinkovitijim.

Dobro za programere

• Iako programeri moraju potrošiti više vremena na pisanje TDD testnih slučajeva, potrebno je puno manje vremena za otklanjanje pogrešaka i razvoj.ping nove značajke. Pisat ćete čišći i manje kompliciran kod.

Pitanja i odgovori