Ce este Test Driven Development (TDD)? Tutorial cu Exemplu

Cuprins:

Anonim

Test Driven Development

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

Test-Driven Development începe cu proiectarea și dezvoltarea testelor pentru fiecare funcționalitate mică a unei aplicații. TDD îi instruiește pe dezvoltatori să scrie un cod nou numai dacă un test automat a eșuat. Acest lucru evită duplicarea codului. Forma completă a TDD este dezvoltarea bazată pe test.

Conceptul simplu de TDD este de a scrie și corecta testele eșuate înainte de a scrie un nou cod (înainte de dezvoltare). Acest lucru ajută la evitarea duplică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 de cerință pe care trebuie să le testăm pentru a le îndeplini).

Dezvoltarea bazată pe test este un proces de dezvoltare și rularea testului automat înainte de dezvoltarea efectivă a aplicației. Prin urmare, TDD numit uneori și Test First Development.

În acest tutorial, veți afla mai multe despre-

  • Cum se efectuează testul TDD
  • TDD vs. Testarea tradițională
  • Ce este TDD de acceptare și TDD pentru dezvoltatori
  • Scalarea TDD prin dezvoltarea modelului Agile Model Driven (AMDD)
  • Test Driven Development (TDD) vs. Dezvoltare bazată pe modelul agil (AMDD)
  • Exemplu de TDD
  • Avantajele TDD

Cum se efectuează testul TDD

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

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

Ciclul TDD definește

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

Câteva clarificări despre TDD:

  • TDD nu este nici despre „Testare”, nici despre „Proiectare”.
  • TDD nu înseamnă „scrieți câteva dintre teste, apoi construiți un sistem care trece testele.
  • TDD nu înseamnă „faceți multe teste”.

TDD vs. 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 reușit 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 dvs. îndeplinește efectiv cerințele definite pentru acesta. Vă ajută să vă construiți încrederea în sistemul dvs.
  • În TDD, accentul este pus mai mult pe codul de producție care verifică dacă testarea va funcționa corect. În testarea tradițională, accentul este pus mai mult pe proiectarea cazurilor de testare. Dacă testul va arăta execuția corectă / necorespunzătoare a aplicației pentru a îndeplini cerințele.
  • În TDD, obțineți un test de acoperire de 100%. Fiecare linie de cod este testată, spre deosebire de testarea tradițională.
  • Combinația atât a testării tradiționale, cât și a TDD duce la importanța testării sistemului mai degrabă decât a perfecționării sistemului.
  • În Modelarea Agilă (AM), ar trebui să „testați cu un scop”. Ar trebui să știți de ce testați ceva și la ce nivel trebuie testat.

Ce este TDD de acceptare și TDD pentru dezvoltatori

Există două niveluri de TDD

  1. Acceptare TDD (ATDD): Cu ATDD scrieți un singur test de acceptare. Acest test îndeplinește cerința 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 a fost, de asemenea, cunoscut sub numele de Behavioral Driven Development (BDD).
  2. Developer TDD: cu Developer TDD scrieți un test de dezvoltator unic, adică test de unitate și apoi doar cod de producție suficient pentru a îndeplini testul respectiv. Testul unitar se concentrează pe fiecare funcționalitate mică a sistemului. Dezvoltatorul TDD este pur și simplu numit TDD.

    Scopul principal al ATDD și TDD este de a specifica cerințe detaliate, executabile pentru soluția dvs. pe o bază just in time (JIT). JIT înseamnă luarea în considerare numai a acelor cerințe care sunt necesare în sistem. Deci creșteți eficiența.

Scalarea TDD prin dezvoltarea modelului Agile Model Driven (AMDD)

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

Astfel, AMDD a folosit pentru probleme mai mari.

Ciclul de viață al AMDD.

În Model-driven Development (MDD), sunt create modele extinse înainte de scrierea codului sursă. Care la rândul lor au o abordare agilă?

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

Imaginarea este unul dintre procesele TDD de predicție / imaginare a testelor care vor fi efectuate în prima săptămână a proiectului. Scopul principal al imaginării este de a identifica domeniul de aplicare al sistemului și arhitectura sistemului. Cerințele la nivel înalt și modelarea arhitecturii sunt realizate pentru o vizualizare 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.

  1. Iterarea 0: previzionarea

Există două sub-active principale.

  1. Previzualizarea cerințelor inițiale.

    Poate dura câteva zile pentru a identifica cerințele la nivel înalt și domeniul de aplicare al sistemului. Accentul principal este explorarea modelului de utilizare, a modelului de domeniu inițial și a modelului de interfață cu utilizatorul (UI).

  2. Vizualizare inițială arhitecturală.

    De asemenea, este nevoie de câteva zile pentru a identifica arhitectura sistemului. Permite stabilirea direcțiilor tehnice pentru proiect. Accentul principal este explorarea diagramelor tehnologice, a fluxului interfeței de utilizator (UI), a modelelor de domeniu și a cazurilor de schimbare.

  1. Modelarea iterației:

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

  • Procesul agil este utilizat pentru fiecare iterație, adică în timpul fiecărei iterații, noul articol de lucru va fi adăugat cu prioritate.
  • Primul lucru cu prioritate mai mare va fi luat în considerare. Articolele de lucru adăugate pot fi reprioritizate sau eliminate din stiva de articole oricând.
  • Echipa discută cum vor implementa fiecare cerință. Modelarea este utilizată în acest scop.
  • Analiza și proiectarea modelării se fac pentru fiecare cerință care urmează să fie implementată pentru acea iterație.
  1. Model de furtună:

    Acest lucru este, de asemenea, cunoscut sub numele de Just in time Modeling.

  • Aici sesiunea de modelare implică o echipă formată din 2/3 membri care discută probleme pe hârtie sau pe tablă.
  • Un membru al echipei îl va cere pe altul să modeleze cu ei. Această sesiune de modelare va dura aproximativ 5-10 minute. Unde membrii echipei se adună împreună pentru a partaja tablă / hârtie.
  • Ei explorează problemele până când nu găsesc cauza principală a problemei. Chiar la timp, dacă un membru al echipei identifică problema pe care dorește să o rezolve, atunci el / ea va primi rapid ajutorul altor membri ai echipei.
  • Alți membri ai grupului apoi explorează problema și apoi toată lumea continuă ca înainte. Se mai numește sub formă de stand-up modeling sau sesiuni de QA pentru clienți.
  1. Test Driven Development (TDD).
  • Promovează testarea confirmativă a codului de aplicație ș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ține documente.
  1. Recenzii.
  • Acest lucru este opțional. Include inspecții de cod și recenzii ale modelului.
  • 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.

Test Driven Development (TDD) vs. Dezvoltare bazată pe modelul agil (AMDD)

TDD AMDD
  • TDD scurtează bucla de feedback a programării
  • AMDD scurtează bucla de feedback de modelare.
  • TDD este o specificație detaliată
  • AMDD funcționează pentru probleme mai mari
  • TDD promovează dezvoltarea unui cod de înaltă calitate
  • AMDD promovează o comunicare de înaltă calitate cu părțile interesate și dezvoltatorii.
  • TDD vorbește programatorilor
  • AMDD discută cu analistii de afaceri, părțile interesate și profesioniștii în domeniul datelor.
  • TDD neorientat vizual
  • AMDD orientat vizual
  • TDD are un domeniu limitat la lucrările software
  • AMDD are un domeniu larg de aplicare, inclusiv părțile interesate. Aceasta implică lucrul către o înțelegere comună
  • Ambele susțin dezvoltarea evoluției
 --------------------------------------------

Exemplu de TDD

Aici, în acest exemplu, 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.

În primul rând, 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 TRECUTĂ așa cum se arată mai jos;

Ieșire :

Scenariul 2 : Aici putem vedea în metoda TestPasswordLength () nu este nevoie de crearea unei instanțe din clasa PasswordValidator. Instanță înseamnă crearea unui obiect de clasă pentru a trimite membrii (variabile / metode) acelei clase.

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

Deci, Refactorizăm (schimbăm codul) după cum urmează:

Scenariul 3 : După refactorizare, ieșirea arată starea eșuată (a se vedea imaginea de mai jos), deoarece am eliminat instanța. Deci, nu există nicio referire la metoda nestatică isValid ().

Deci, trebuie să schimbăm această metodă adăugând un cuvânt „static” înainte de Boolean ca boolean static static publicValid (parola String). Refactoring Class PasswordValidator () pentru a elimina eroarea de mai sus pentru a trece testul.

Ieșire:

După efectuarea modificărilor la clasa PassValidator () dacă executăm testul, ieșirea va fi PASSED așa cum se arată mai jos.

Avantajele TDD

  • 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, în timp, o suită de teste automate pe care dvs. ș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 modul în care codul va fi utilizat și cum interacționează cu alte module.
    • Rezultă o decizie de proiectare mai bună și un cod mai ușor de întreținut.
    • TDD permite scrierea unui cod mai mic având o singură responsabilitate, mai degrabă decât proceduri monolitice cu responsabilități multiple. Acest lucru face codul mai simplu de înțeles.
    • TDD forțează, de asemenea, să scrie doar codul de producție pentru a trece testele pe baza cerințelor utilizatorului.
  • Încrederea în Refactor
    • Dacă refaceti codul, pot exista posibilități de pauze în cod. Deci, având un set de teste automate, puteți remedia aceste pauze înainte de lansare. Va fi dat un avertisment adecvat dacă se constată întreruperi atunci când se utilizează teste automate.
    • Folosind TDD, ar trebui să se obțină un cod mai rapid, mai extensibil, cu mai puține erori care pot fi actualizate cu riscuri minime.
  • Bun pentru munca în echipă

    În absența unui membru al echipei, alți membri ai echipei pot prelua și lucra cu ușurință la cod. 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 scriind cazuri de test TDD, este nevoie de mult mai puțin timp pentru depanare și dezvoltarea de noi caracteristici. Veți scrie cod mai curat, mai puțin complicat.

Rezumat:

  • TDD înseamnă dezvoltarea bazată pe test. Este un proces de modificare a codului pentru a trece un test proiectat anterior.
  • Se pune mai mult accent pe codul de producție decât pe proiectarea cazului de testare.
  • Dezvoltarea bazată pe test este un proces de modificare a codului pentru a trece un test proiectat anterior.
  • În Ingineria Software-ului, este uneori cunoscut sub numele de „Test First Development”.
  • TDD include refactorizarea unui cod, adică modificarea / adăugarea unei cantități de cod la codul existent, fără a afecta comportamentul acestuia.
  • Atunci când este utilizat, codul devine mai clar și mai ușor de înțeles.

Acest articol este contribuit de Kanchan Kulkarni