ce este dezvoltarea bazată pe teste (TDD)?

large__8282043567dezvoltarea bazată pe teste este un proces care se bazează pe repetarea unui ciclu de dezvoltare foarte scurt. Se bazează pe primul concept de testare Extreme Programming (XP) care încurajează designul simplu, cu un nivel ridicat de încredere.

procedura de a face TDD este următoarea:

  1. scrieți un test
  2. rulați toate testele
  3. scrieți codul de implementare
  4. rulați toate testele
  5. Refactor

această procedură este adesea numită Red-Green-Refactor.

în timp ce scriem teste, suntem în starea roșie. Deoarece testul este scris înainte de punerea în aplicare efectivă, se presupune că nu reușește. Dacă nu, testul este greșit. Descrie ceva care există deja sau a fost scris incorect. A fi în verde în timp ce scrieți teste este un semn de fals pozitiv. Testele de genul acesta ar trebui eliminate sau refactorizate.

urmează statul verde. Când implementarea ultimului test este terminată, toate testele ar trebui să treacă. Dacă nu, implementarea este greșită și ar trebui corectată.

ideea nu este de a face implementarea finală, ci de a oferi suficient cod pentru ca testele să treacă. Odată ce totul este verde, putem continua să refactorizăm codul existent. Asta înseamnă că facem Codul mai optim fără a introduce noi caracteristici. În timp ce refactorizarea este în vigoare, toate testele ar trebui să treacă tot timpul. Dacă unul dintre ei nu reușește, refactor a rupt o funcționalitate existentă. Refactorizarea nu trebuie să includă teste noi.

viteza este cheia

large_5836417589
am tendința de a vedea TDD ca un joc de ping-pong (sau tenis de masă). Jocul este foarte rapid. Același lucru este valabil și pentru TDD. Am tendința să nu petrec mai mult de un minut pe fiecare parte a mesei (testare și implementare). Scrieți un test scurt și rulați-l (ping), scrieți implementarea și rulați toate testele (pong), scrieți un alt test (ping), scrieți implementarea acelui test (pong), refactor și confirmați că toate testele trec (scor), repetați. Ping, pong, ping, pong, ping, pong, scor, servi din nou. Nu încercați să faceți codul perfect. În schimb, încercați să păstrați mingea rulând până când credeți că este momentul potrivit pentru a înscrie (refactor).

nu este vorba despre testarea

T în TDD este adesea înțeles greșit. TDD este modul în care abordăm designul. Este modalitatea de a ne forța să ne gândim la implementare înainte de a scrie codul. Acesta este modul de a structura mai bine codul. Asta nu înseamnă că testele rezultate din utilizarea TDD sunt inutile. Departe de asta. Sunt foarte utile și ne permit să ne dezvoltăm cu mare viteză, fără să ne temem că ceva va fi rupt. Acest lucru este valabil mai ales atunci când are loc refactorizarea. Posibilitatea de a reorganiza codul în timp ce aveți încrederea că nicio funcționalitate nu este ruptă este un impuls imens pentru calitatea codului.

obiectivul principal al TDD este proiectarea codului cu teste ca produs secundar foarte util.

batjocoritor

pentru ca testele să ruleze rapid, oferind astfel un feedback constant, codul trebuie să fie organizat într-un mod care metode, funcții și clase pot fi ușor batjocorit și stubbed. Viteza de execuție va fi grav afectată, de exemplu, testele noastre trebuie să comunice cu baza de date. Batjocorind dependențele externe suntem capabili să creștem această viteză drastic. Executarea suitei de teste unitare întregi trebuie măsurată în minute, dacă nu în secunde. Mai important decât viteza, proiectarea codului într-un mod care poate fi ușor batjocorit și înțepenit ne obligă să structurăm mai bine acel cod prin aplicarea separării preocupărilor. Cu sau fără batjocuri, codul ar trebui să fie scris într-un mod în care putem, de exemplu, să înlocuim cu ușurință o bază de date cu alta. Că” altul ” poate fi, de exemplu, baza de date batjocorită sau în memorie.

un exemplu de batjocură în Scala poate fi găsit în Scala Test-Driven Development (TDD): Unit Testing file Operations with Specs2 și Mockito articol. Dacă limbajul dvs. de programare ales nu este Scala, articolul poate fi în continuare foarte util pentru a vedea modelul care poate fi aplicat oricărei limbi.

observatorii

instrument foarte util atunci când se lucrează în moda TDD sunt observatorii. Sunt cadre sau instrumente care sunt executate înainte de a începe să lucrăm și urmăresc orice modificare a codului. Când se detectează o astfel de modificare, Toate testele sunt executate. În cazul JavaScript, aproape toate sistemele de construire și alergătorii de sarcini permit acest lucru. Gulp (preferatul meu) și Grunt sunt două din multe exemple. Scala are sbt-revolver (printre altele). Majoritatea celorlalte limbaje de programare au instrumente similare care recompilează (dacă este necesar) și rulează toate testele (sau afectate) atunci când codul se schimbă. Întotdeauna ajung să am ecranul împărțit în două ferestre. Unul cu codul la care lucrez și celălalt cu rezultatele testelor care sunt executate continuu. Tot ce trebuie să fac este să fiu atent că ieșirea acelor observatori corespunde fazei în care mă aflu (roșu sau verde).

documentație

un alt efect secundar foarte util al TDD (și teste bine structurate în general) este documentația. În cele mai multe cazuri, este mult mai ușor să aflați ce face codul analizând testele decât implementarea în sine. Avantajul suplimentar pe care alte tipuri de documentație nu îl pot oferi este că testele nu sunt niciodată depășite. Dacă există vreo discrepanță între teste și Codul de implementare, testele eșuează. Testele eșuate înseamnă documentație inexactă.

teste ca articol de documentare oferă un raționament puțin mai profund în spatele utilizării testelor în loc de documentația tradițională.

rezumat

din experiența mea, TDD este probabil cel mai important instrument pe care îl avem în setul nostru de instrumente software. Este nevoie de mult timp și răbdare pentru a deveni competenți în TDD, dar odată ce arta este stăpânită, productivitatea și calitatea cresc drastic. Cel mai bun mod de a învăța și de a practica TDD este în combinație cu programarea perechilor. Ca într-un joc de ping pong care necesită doi participanți, TDD poate fi în perechi în care un coder scrie teste, iar celălalt scrie implementarea acestor teste. Rolurile se pot schimba după fiecare test (așa cum se face adesea în codarea Dojo-urilor).

încercați și nu renunțați atunci când vă confruntați cu obstacole, deoarece vor fi multe.

Test Driven Development (TDD): cele mai bune practici folosind exemple Java este un bun punct de plecare. Chiar dacă folosește exemple Java, aceleași, dacă nu toate, practicile pot fi aplicate oricărui limbaj de programare. Pentru un exemplu în Java (ca în cazul precedent, este ușor de aplicat în alte limbi), vă rugăm să aruncați o privire la articolul TDD Example Walkthrough.

o altă modalitate excelentă de a perfecționa abilitățile TDD sunt codul Kata (există multe pe acest site).

care este experiența dumneavoastră cu TDD? Există la fel de multe variante pe cât există Echipe care o practică și aș vrea să aud despre experiența ta.

Lasă un răspuns

Adresa ta de email nu va fi publicată.