Ce este Test Driven Development (TDD)? Exemplu

Ce este Test Driven Development (TDD)?

Dezvoltare bazată pe teste (TDD) este o abordare de dezvoltare software în care sunt dezvoltate cazuri de testare pentru a specifica și valida ceea ce va face codul. În termeni simpli, cazurile de testare pentru fiecare funcționalitate sunt create și testate mai întâi, iar dacă testul eșuează, atunci noul cod este scris pentru a trece testul și a face codul simplu și fără erori.

Dezvoltarea bazată pe teste începe cu proiectarea și dezvoltarea de teste pentru fiecare funcționalitate mică a unei aplicații. Cadrul TDD instruiește dezvoltatorii să scrie cod nou numai dacă un test automat a eșuat. Acest lucru evită duplicarea codului. Forma completă a TDD este o dezvoltare bazată pe teste.

Conceptul simplu al TDD este să scrieți și să corectați testele eșuate înainte de a scrie cod nou (înainte de dezvoltare). Acest lucru ajută la evitarea dublării codului, deoarece scriem o cantitate mică de cod la un moment dat pentru a trece testele. (Testele nu sunt altceva decât condiții obligatorii pe care trebuie să le testăm pentru a le îndeplini).

Dezvoltarea bazată pe teste este un proces de dezvoltare și rulare a unui test automat înainte de dezvoltarea efectivă a aplicației. Prin urmare, TDD uneori numit și ca Testează prima dezvoltare.

Cum se efectuează testul TDD

Următorii pași definesc modul de realizare a testului TDD,

1. Adăugați un test.
2. Rulați toate testele și vedeți dacă vreun nou test eșuează.
3. Scrie un cod.
4. Rulați teste și Refactorați codul.
5. Repeta.

Ciclul TDD definește

1. Scrieți un test
2. Fă-l să alerge.
3. Schimbați codul pentru a-l face corect, adică Refactor.
4. Repetați procesul.

Câteva precizări despre TDD:

• Abordarea TDD nu este nici despre „testare”, nici despre „proiectare”.
• TDD nu înseamnă „scrieți unele dintre teste, apoi construiți un sistem care trece testele.
• TDD nu înseamnă „fă multe teste”.

TDD vs. Testare tradițională

Mai jos este diferența principală dintre dezvoltarea bazată pe teste și testarea tradițională:

Abordarea TDD este în primul rând o tehnică de specificare. Se asigură că codul sursă este testat temeinic la nivel de confirmare.

• Cu testarea tradițională, un test de succes găsește unul sau mai multe defecte. Este la fel ca TDD. Când un test eșuează, ați făcut progrese deoarece știți că trebuie să rezolvați problema.
• TDD se asigură că sistemul dumneavoastră îndeplinește de fapt cerințele definite pentru acesta. Vă ajută să vă construiți încrederea în sistemul dvs.
• În TDD, un accent mai mare se pune pe codul de producție care verifică dacă testarea va funcționa corect. În testarea tradițională, se pune mai mult accent pe proiectarea cazului de testare. Dacă testul va arăta execuția corectă/improprie a aplicației pentru a îndeplini cerințele.
• În TDD, obțineți un test de acoperire 100%. Fiecare linie de cod este testată, spre deosebire de testarea tradițională.
• Combinația dintre testarea tradițională și TDD duce la importanța testării sistemului mai degrabă decât la perfecțiunea sistemului.
• In Modelare agilă (AM), ar trebui să „testați cu un scop”. Ar trebui să știi de ce testezi ceva și la ce nivel trebuie testat.

Ce este acceptarea TDD și Developer TDD

Există două niveluri de TDD

1. TDD de acceptare (ATDD): Cu ATDD scrii un singur test de acceptare. Acest test îndeplinește cerințele specificației sau satisface comportamentul sistemului. După aceea, scrieți suficient cod de producție/funcționalitate pentru a îndeplini acel test de acceptare. Testul de acceptare se concentrează pe comportamentul general al sistemului. ATDD era, de asemenea, cunoscut ca Dezvoltare bazată pe comportament (BDD).
2. Dezvoltator TDD: Cu Developer TDD scrieți un singur test de dezvoltator, adică un test unitar și apoi doar suficient cod de producție pentru a îndeplini acel test. Testul unitar se concentrează pe fiecare funcționalitate mică a sistemului. Dezvoltatorul TDD este numit pur și simplu ca TDD.Scopul principal al ATDD și TDD este de a specifica cerințe detaliate, executabile pentru soluția dvs. pe o bază JIT (just in time). JIT înseamnă luarea în considerare numai a acelor cerințe care sunt necesare în sistem. Deci crește eficiența.

Scalare TDD prin Agile Model Driven Development (AMDD)

TDD este foarte bun la specificații detaliate și la validare. Nu reușește să se gândească la probleme mai mari, cum ar fi designul general, utilizarea sistemului sau UI. AMDD abordează problemele de scalare Agile pe care TDD nu le abordează.

Astfel, AMDD este folosit pentru probleme mai mari.

Ciclul de viață al AMDD

În Model-driven Development (MDD), modele extinse sunt create înainte ca codul sursă să fie scris. Care, la rândul lor, au o abordare agilă?

În figura de mai sus, fiecare casetă reprezintă o activitate de dezvoltare.

Vizionarea este unul dintre testele TDD de predicție/imaginare care vor fi efectuate în prima săptămână a proiectului. Scopul principal al viziunii este de a identifica domeniul de aplicare al sistemului și arhitectura sistemului. Cerințe de nivel înalt și modelarea arhitecturii este realizată pentru o imagine de succes.

Este procesul în care nu se face o specificație detaliată a software-ului/sistemului, ci explorarea cerințelor software-ului/sistemului care definește strategia generală a proiectului.

Iterația 0: Vizionare

Există două sub-activări principale.

1. Prevederea cerințelor inițiale.Poate dura câteva zile pentru a identifica cerințele de nivel înalt și domeniul de aplicare al sistemului. Accentul principal este de a explora modelul de utilizare, modelul de domeniu inițial și modelul de interfață cu utilizatorul (UI).
2. Inițială Archiviziune tecturală. De asemenea, este nevoie de câteva zile pentru a identifica arhitectura sistemului. Permite stabilirea de direcții tehnice pentru proiect. Accentul principal este de a explora diagramele tehnologice, fluxul de interfață cu utilizatorul (UI), modelele de domenii și cazurile de modificare.

Modelarea iterației

Aici echipa trebuie să planifice munca care va fi făcută pentru fiecare iterație.

• Procesul agil este utilizat pentru fiecare iterație, adică în timpul fiecărei iterații, un nou articol de lucru va fi adăugat cu prioritate.
• Mai întâi va fi luată în considerare munca cu prioritate mai mare. Elementele de lucru adăugate pot fi prioritizate sau eliminate din stiva de articole oricând.
• Echipa discută cum va implementa fiecare cerință. Modelarea este folosită în acest scop.
• Analiza modelării și proiectarea se realizează pentru fiecare cerință care urmează să fie implementată pentru acea iterație.

Asalt model

Acest lucru este cunoscut și sub denumirea de Modelare Just in time.

• Aici sesiunea de modelare implică o echipă de 2/3 membri care discută probleme pe hârtie sau pe tablă.
• Un membru al echipei îi va cere altuia să modeleze cu ei. Această sesiune de modelare va dura aproximativ 5 până la 10 minute. Unde membrii echipei se adună pentru a împărtăși tablă albă/hârtie.
• Ei explorează problemele până când nu găsesc cauza principală a problemei. La timp, dacă un membru al echipei identifică problema pe care dorește să o rezolve, atunci el/ea va primi ajutor rapid de la alți membri ai echipei.
• Apoi alți membri ai grupului explorează problema și apoi toată lumea continuă ca înainte. Se mai numește și modelare stand-up sau sesiuni de QA pentru clienți.

Dezvoltare bazată pe teste (TDD)

• Promovează testarea de confirmare a codului aplicației și specificațiile detaliate.
• Atât testul de acceptare (cerințe detaliate) cât și testele dezvoltatorului (testul unitar) sunt intrări pentru TDD.
• TDD face codul mai simplu și mai clar. Permite dezvoltatorului să mențină mai puțină documentație.

Recenzii

• Acest lucru este opțional. Include inspecții de cod și revizuiri de model.
• Acest lucru se poate face pentru fiecare iterație sau pentru întregul proiect.
• Aceasta este o opțiune bună pentru a oferi feedback pentru proiect.

Dezvoltare bazată pe teste (TDD) vs. Dezvoltare Agile Model Driven (AMDD)

TDD	AMDD
TDD scurtează bucla de feedback de programare	AMDD scurtează bucla de feedback de modelare.
TDD este o specificație detaliată	AMDD funcționează pentru probleme mai mari
TDD promovează dezvoltarea de coduri de înaltă calitate	AMDD promovează comunicarea de înaltă calitate cu părțile interesate și dezvoltatorii.
TDD vorbește cu programatorii	AMDD vorbește cu Business Analyst, părțile interesate și profesioniștii datelor.
TDD orientat nevizual	AMDD orientat vizual
TDD are un domeniu de aplicare limitat la lucrările software	AMDD are un domeniu de aplicare larg, inclusiv părțile interesate. Implică lucrul spre o înțelegere comună
Ambele sprijină dezvoltarea evolutivă	---------------

Cadre TDD

Iată lista celor mai bune cadre de dezvoltare bazată pe teste (TDD).

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

Acum, să învățăm Test Driven Development prin exemplu.

Exemplu de TDD

Aici, în acest exemplu de dezvoltare condusă de testare, vom defini o parolă de clasă. Pentru această clasă, vom încerca să îndeplinim următoarele condiții.

O condiție pentru acceptarea parolei:

• Parola trebuie să aibă între 5 și 10 caractere.

Mai întâi în acest exemplu TDD, scriem codul care îndeplinește toate cerințele de mai sus.

Scenariul 1: Pentru a rula testul, creăm clasa PasswordValidator ();

Vom rula deasupra clasei TestPassword ();

Ieșirea este PASSĂ așa cum se arată mai jos;

producție:

Scenariul 2: Aici putem vedea în metoda TestPasswordLength () nu este nevoie de a crea o instanță a clasei PasswordValidator. Instanță înseamnă crearea unui obiect de clasă pentru a trimite membrii (variabile/metode) clasei respective.

Vom elimina clasa PasswordValidator pv = new PasswordValidator () din cod. Putem apela la este valabil () metoda direct prin PasswordValidator. IsValid („Abc123”). (Vezi imaginea de mai jos)

Deci refactorăm (schimbăm codul) după cum urmează:

Scenariul 3: După refactorizare, ieșirea arată starea eșuată (vezi imaginea de mai jos), acest lucru se datorează faptului că am eliminat instanța. Deci nu există nicio referire la metoda non-statică este valabil ().

Așadar, trebuie să schimbăm această metodă adăugând cuvântul „static” înainte de boolean ca boolean static public isValid (parolă șir). Refactoring Class PasswordValidator () pentru a elimina eroarea de mai sus pentru a trece testul.

ieșire:

După ce facem modificări la clasa PassValidator (), dacă rulăm testul, ieșirea va fi PASSĂ așa cum se arată mai jos.

Avantajele TDD

Următoarele sunt principalele avantaje ale dezvoltării bazate pe teste în ingineria software:

Notificare timpurie a erorilor.

• Dezvoltatorii își testează codul, dar în lumea bazelor de date, acesta constă adesea în teste manuale sau scripturi unice. Folosind TDD, construiți, de-a lungul timpului, o suită de teste automate pe care dumneavoastră și orice alt dezvoltator le puteți relua după bunul plac.

Cod mai bine conceput, mai curat și mai extensibil.

• Vă ajută să înțelegeți cum va fi utilizat codul și cum interacționează cu alte module.
• Rezultă o decizie mai bună de proiectare și un cod mai ușor de întreținut.
• TDD permite scrierea unui cod mai mic cu responsabilitate unică, mai degrabă decât proceduri monolitice cu responsabilități multiple. Acest lucru face codul mai ușor de înțeles.
• De asemenea, TDD forțează să scrie doar cod de producție pentru a trece testele bazate pe cerințele utilizatorului.

Încrederea în Refactor

• Dacă refactorizați codul, pot exista posibilități de întrerupere în cod. Deci, având un set de teste automate, puteți remedia acele întreruperi înainte de lansare. Se va da avertismentul corespunzător dacă se găsesc pauze atunci când sunt utilizate teste automate.
• Utilizarea TDD ar trebui să aibă ca rezultat un cod mai rapid, mai extensibil, cu mai puține erori care pot fi actualizate cu riscuri minime.

Bun pentru lucrul în echipă

• În absența oricărui membru al echipei, alți membri ai echipei pot prelua cu ușurință codul și pot lucra la el. De asemenea, ajută la schimbul de cunoștințe, făcând astfel echipa mai eficientă în general.

Bun pentru dezvoltatori

• Deși dezvoltatorii trebuie să petreacă mai mult timp în scrierea cazurilor de testare TDD, este nevoie de mult mai puțin timp pentru depanare și dezvoltarea de noi funcții. Veți scrie un cod mai curat, mai puțin complicat.

Rezumat

• TDD înseamnă Test-driven development.
• Sensul TDD: Este un proces de modificare a codului pentru a trece un test proiectat anterior.
• Se pune mai mult accent pe codul de producție, mai degrabă decât pe designul cazului de testare.
• Dezvoltarea bazată pe teste este un proces de modificare a codului pentru a trece un test proiectat anterior.
• In Inginerie Software, Este uneori cunoscut ca „Testează mai întâi dezvoltarea.”
• Testarea TDD include refactorizarea unui cod, adică schimbarea/adăugarea unei cantități de cod la codul existent fără a afecta comportamentul codului.
• Programarea TDD atunci când este utilizat, codul devine mai clar și ușor de înțeles.