De ce ar trebui să practică Test Driven Development și cum ar trebui să încep?

O mulțime de oameni vorbesc despre scrierea de teste pentru codul lor înainte de a începe să scrie codul lor. Această practică este, în general, cunoscută ca Test Driven Development sau TDD pe scurt. Ce beneficii obțin din scrierea de software în acest fel? Cum pot să încep cu această practică?

0
fr hi bn
Am întârziat aici, dar aș vrea să îmi pun octetul. Cea mai bună abordare a practicii TDD utilizează Katas. Aici sunt bune katas cu teste: github.com/garora/TDD-Katas
adăugat autor Gaurav Aroraa, sursa
Vedeți răspunsul meu la aceeași întrebare deja întrebată. Un răspuns elaborat la această întrebare
adăugat autor eroijen, sursa

6 răspunsuri

Există multe avantaje:

  • Aveți feedback imediat dacă codul dvs. funcționează, astfel încât să puteți găsi bug-uri mai rapid
  • Văzând că testul trece de la roșu la verde, știi că ai atât un test de regresie de lucru, cât și un cod de lucru
  • Ai încredere în refactorizarea codului existent, ceea ce înseamnă că poți curăța codul fără să te îngrijorezi de ce s-ar putea rupe
  • La sfârșit aveți o serie de teste de regresie care pot fi executate în timpul construcțiilor automate, pentru a vă oferi mai multă încredere în faptul că baza dvs. de cod este solidă

Cel mai bun mod de a începe este să începeți. Există o minunată carte de Kent Beck despre Test Driven Development. Doar începeți cu cod nou, nu vă faceți griji cu privire la codul vechi ... ori de câte ori credeți că trebuie să refaceți un cod, să scrieți un test pentru funcționalitatea existentă, apoi să îl refacționați și să vă asigurați că încercările rămân verde. De asemenea, citiți acest articol minunat .

0
adăugat
legătura cu ultimul articol (Sfaturi pentru testarea unităților) a expirat. Iată linkul la noul articol: devver.wordpress. com / 2008/07/07 / sfaturi-pentru-unitate de testare
adăugat autor Igor Popov, sursa

Beneficii

  1. Vă dați seama cum să vă compartmentalizați codul
  2. Vă dați seama exact ce doriți să faceți codul dvs.
  3. Știi cum ar trebui să acționeze și, pe drum, dacă refactoringul va sparge ceva
  4. Obțineți obiceiul de a vă asigura că codul dvs. știe întotdeauna ce trebuie să facă

Noțiuni de bază

Doar fa-o. Scrieți un test pentru ceea ce doriți să faceți și apoi scrieți codul care ar trebui să treacă testul. Dacă treceți testul, minunat, puteți trece la scrierea cazurilor în care codul dvs. va eșua întotdeauna (de exemplu, 2 + 2 nu trebuie să fie egal cu 5).

Odată ce toate testele dvs. trec, scrieți-vă logica reală de afaceri pentru a face ce vreți să faceți.

Dacă începeți de la zero, asigurați-vă că găsiți o suită de testare bună, ușor de utilizat. Îmi place PHP atât PHPUnit cât și SimpleTest funcționează bine. Aproape toate limbile populare au o suită de testare xUnit disponibilă pentru a ajuta la construirea și automatizarea testelor.

0
adăugat
Apropo, "compartmentalizați codul" vă conduc către o arhitectură foarte bună "gratuit". Când rupeți codurile în bucăți pentru a le testa, veți ajunge la o arhitectură mai bună. Este destul de liber dacă aveți puțină experiență de arhitect software.
adăugat autor daitangio, sursa

Partea beneficiilor a fost acoperită recent , ca și în cazul în care să începeți .... pe un sistem mic unde nu există prea multe necunoscute, astfel încât riscurile sunt scăzute. Dacă nu cunoașteți deja un cadru de testare (cum ar fi NUnit), începeți să învățați acest lucru. În caz contrar începeți prin a scrie primul dvs. test :)

0
adăugat
Link-ul este rupt!
adăugat autor Nagaraj Tantri, sursa

În opinia mea, cel mai mare lucru este că vă permite în mod clar să vedeți dacă codul dvs. face ceea ce se presupune. Acest lucru poate părea evident, dar este foarte ușor să vă rătăciți de obiectivele originale, așa cum am aflat în trecut: p

0
adăugat

Good starter: Getting Started with Tdd in Java using Eclipse by Brett L. Schuchert

Este un set de scenarii despre TDD în Java și în C #. Acesta pornește de la zero și de bază de predare a TDD.

0
adăugat

S-ar putea să lucrați într-un mediu agil sau în cascadă. Poate că aveți proceduri bine definite, care au fost testate de luptă prin ani de muncă grea, sau poate că ați început propria dvs. inițiere. Indiferent de situație, probabil că ați întâmpinat cel puțin una, dacă nu chiar mai mult, următoarele dureri, probleme sau cauze pentru livrarea nereușită:

  • O parte a echipei dvs. este ținută în afara buclă în timpul creării cerințelor, specificațiilor sau poveștilor utilizatorilor
  • Cele mai multe, dacă nu toate, dintre testele dvs. sunt manuale sau nu aveți deloc teste
  • Chiar dacă aveți teste automate, acestea nu detectează probleme reale
  • Testele automate sunt scrise și executate atunci când este prea târziu pentru ca acestea să ofere o valoare reală proiectului
  • Există întotdeauna ceva mai urgent decât dedicarea timpului pentru testare
  • Echipele sunt împărțite între departamentele de testare, dezvoltare și analiză funcțională și deseori nu se sincronizează.
  • O incapacitate de a reface codul din cauza temerii că ceva va fi rupt
  • Costul de întreținere este prea mare
  • Timpul-la-piață este prea mare
  • Clienții nu cred că ceea ce a fost livrat este ceea ce au cerut
  • Documentația nu este actualizată
  • Ți-e frică să te proiectezi pentru că rezultatul este necunoscut
  • Adesea nu reușiți să vă deplasați la producție, deoarece testele de regresie durează prea mult pentru a rula
  • Echipa petrece prea mult timp încercând să afle ce înseamnă o anumită metodă sau o clasă

Dezvoltarea bazată pe dezvoltare nu rezolvă în mod magic toate aceste probleme. În schimb, ne pune pe calea spre soluție. Nu există un glonț de argint, dar dacă există o practică de dezvoltare care poate face diferența pe atât de multe niveluri, această practică este TDD.Test-driven de dezvoltare accelerează timpul-la-piață, permite refactoring mai ușor, ajută la crearea unui design mai bun , și încurajează cuplarea mai ușoară. Pe lângă avantajele directe, TDD este o condiție prealabilă pentru multe alte practici (livrarea continuă fiind una dintre ele). Designul mai bun, codul bine scris, timpul mai rapid spre piață, documentația actualizată și acoperirea solidă a testelor sunt câteva dintre rezultatele pe care le veți realiza prin aplicarea TDD.

0
adăugat