TESTAREA SOFTWARE ÎN DEZVOLTAREA SOFTWARE AGILĂ: METODOLOGIA TEST-DRIVEN-DEVELOPMENT DRĂGAN ALEXANDRU-NICOLAE alexdragan24@yahoo.ro Cibernetică,… [604563]

TESTAREA SOFTWARE ÎN DEZVOLTAREA
SOFTWARE AGILĂ: METODOLOGIA
TEST-DRIVEN-DEVELOPMENT

DRĂGAN ALEXANDRU-NICOLAE
[anonimizat]
Cibernetică, Statistică si Informatică Economică, anul III, grupa 1069

REZUMAT
Test-driven development este o metodolige extrem de utilă în dezvoltarea software
care constă în scrierea testelor ș i mai apoi a codului executabil. În produc ț ie se întâmplă de
regulă ca un client să ceară anumite specifica ț ii ale unui sistem informatic, iar acestea să nu
fie întelese de către dezvoltatorii software ș i astfel rezultatul să nu fie cel a ș teptat de către
client. Astfel se pierd resurse financiare ș i timp pentru rescriere.
Metodologia extreme programming a fost inventată pentru a-i ajuta pe programatori
sa în ț eleagă mai bine spec ifica ț iile. Un concept important în extre me programming este chiar
TDD. Acesta ajută la crearea codului orientat pe nevoile clientului ș i spre testare. Chiar dacă
se va scrie mai mult cod, timpul de implementare propriu-zis va fi mai mic.
Ini ț ial toate testele trebuie sa pice, deoarece nu au cod în spate pe care să se bazeze.
Asta fiind un lucru bun deoarece îl for ț eaza pe dezvoltator să se axeze pe specifiica ț ii. Mai
apoi testul este făcut să treacă indiferent, iar apoi se trece la refactorizare. Acest proces se
repetă până la terminarea proiectului.
Scriind teste pentru fiecare modul poate încărca munca programatorului, însă în
momentul când toate testele sunt rulate, fie manual fie automat, iar rezultatul este cel a ș teptat,
atunci încrederea dezvoltatorului software cre ș te, devenind mai productiv.

CUVINTE CHEIE
Extreme programming este o metodologie de dezvoltare software care îmbunătă ț e ș te
calitatea codului ș i ajută l a crearea de aplica ț ii flexibile la schimbările clientului.
User story este un limbaj informal de descriere a specifica ț iilor unei aplica ț ii.
1

Diagrama cazurilor de utilizare prezintă o colec ț ie de cazuri de utilizare ș i actori care
oferă o descriere generală a modului în care va fi utilizat sistemul informatic.
Framework-ul oferă func ț ionalitate generică care poate fi modificată selectiv de către
programator prin cod suplimentar, realizând astfel software-ul necesar unei aplica ț ii.
Programare orientată pe obiecte este o paradigmă de programare, axată pe ideea
încapsulării, a grupării datelor ș i codului care operează asupra lor, într-o singură structură.

TESTAREA SOFTWARE ÎN DEZVOLTAREA SOFTWARE AGILĂ: METODOLOGIA
TEST-DRIVEN-DEVELOPMENT
REZUMAT 1
CUVINTE CHEIE 1
INTRODUCERE 3
CICLUL DE DEZVOLTARE TEST-DRIVEN DEVELOPMENT 3
PROCESUL DE DEZVOLTARE 5
PROCES ÎN CARE ESTE APLICAT TDD 6
BUNE PRACTICI ÎN TDD 7
BENEFICIILE CONCEPTULUI DE TEST-DRIVEN DEVELOPMENT 8
LIMITĂRILE CONCEPTULUI DE TEST-DRIVEN DEVELOPMENT 9
TEST-DRIVE-WORK 9
TDD & ADD 9
TDD & BDD 10
SOFTWARE PENTRU TDD 10
TEST-DRIVEN DATABASE DEVELOPMENT 11
DOCUMENTA Ț IA DESPRE TDD 11
CONCLUZII 12
BIBLIOGRAFIE 12

2

INTRODUCERE

Test-driven-development este un proces de dezvoltare software care constă în
repetarea unor cicluri de dezvoltare foarte scurte. Specifica ț iile sunt transformate în test
case-uri, apoi soft-ul este imbunătătit astfel încât să treacă doar noile teste. Metodologia a fost
dezvoltată de Kent Beck în anul 2003. El consideră că TDD inspiră încredere ș i simplitate în
dezvoltarea software. În conceptul de programarea “extreme programming”, dezvoltat în
1999, test-driven development se regăseste prin conceptul de testare înainte de dezvoltare.
Rezultatele utilizării acestui concept constau într-o suită de teste care pot rula la orice oră
oferind un feedback despre calitatea software-ului. Cartea “Test Driven Development by
Example” oferă o serie de 5 pă ș i repetitivi pentru acest proces.

CICLUL DE DEZVOLTARE TEST-DRIVEN DEVELOPMENT

Primul pas îl reprezintă adăugarea unui test. Dezvoltatorul trebuie să inteleagă foarte
bine specifica ț iile clientu lui astfel încât să fie capabil să scrie un test înaintea codului
propriu-zis. Poate face acest lucru folosindu-se de user stories sau de diagrama cazurilor de
utilizare ș i poate scrie tes tele în orice framework de testare apropiat de tehnologia de bază a
proiectului. Poate fi chiar ș i o versiune modificată a unui test deja existent. Diferen ț a supremă
dintre TDD ș i testarea un itară este acea că TDD îl obligă pe dezvoltator să se axeze în detaliu
pe specifica ț iile clientulu i înainte de a se apuca de implementarea propriu zisă, pe când
testarea unitară se face abia după ce procesul de dezvoltare a fost încheiat.
Al doilea pas constă în rularea tuturor testelor pentru a verifica dacă doar noile teste
pică. Asta demonstrează că noile teste nu au cum să treacă deoarece codul aferent lor nu a
fost încă scris. Noile teste ar trebui să pice doar în scenarii controlate.
Pasul trei constă în scrierea codului care face testul anterior scris să treacă. Codul
scris în această fază poate să nu fie perfect ș i poate să treacă testul într-un mod inteligent.
Acest lucru este acceptat deoarece codul urmează să fie îmbunătă ț it. La acest pas tot ce
contează este trecerea testului.
Pasul patru constă în rularea testelor. Dacă codul trece toate testele atunci
dezvoltatorul software poate fi încrezător în faptul că programul întrune ș te toate specifica ț iile
ș i nu strică în vreun fel in tegrarea acestuia cu codul deja existent. Dacă nu, atunci codul
trebuie ajustat.
Ultimul pas constă în refactorizare. Bucă ț ile de cod duplicate trebuie să dispară, astfel
respectându-se conceptul de DRY -“Do not Repeat Yourself”. Codul duplicat se trece într-o
metodă ș i se apelează me toda. Obiectele, clasele, metodele ș i variabilele trebuie să aibă nume
sugestiv în conformitate cu func ț ionalitatea fiecăruia. Pe măsură ce func ț ionalitatea este
adăugată, corpul metodelor devine din ce în ce mai lung. Este recomandat să fie împăr ț ite în
3

bucă ț i mai mici pentru a f i mai u ș or de între ț inut pe viitor. Asta va îmbunătă ț i ciclul de via ț ă
al software-ului. Există ghidaje specifice despre cum ar trebui codul să fie refactorizat ș i este
recomandată implementarea design pattern-urilor potrivite. Rulând testele pe măsură ce
programatorul cura ț ă cod ul îi oferă acestuia siguran ț ă că nu strică nimic în procesul de
refactorizare.

Începând cu un nou test, ciclul este repetat până se finalizează proiectul. Dacă noul
cod nu trece un test rapid sau pică nea ș teptat atunci trebuie să se revină la o versiune
anterioară. Continuous integration (CI) ajută oferind numeroare puncte de întoarcere.
Scopul principal al CI este cel de a evita problemele de integrare, denumite
„integration hell”, în primele descrieri de extreme programming (XP). Continuous
integration poate fi văzută ca o intensificare a practicilor de integrare periodică promovate de
metodele deja publicate ale dezvoltării de software prin proces incremental-iterativ, cum ar fi
metoda Booch. CI nu este universal acceptat ca o îmbunătă ț ire fa ț ă de integrarea frecventă,
cele două rămânând două forme distincte. Continuous integration a fost creat la început cu
inten ț ia de a fi utilizat în combina ț ie cu testele automate scrise pr in practicile de test-driven
4

development, ceea ce a presupus rularea tuturor testelor unitare ș i verificarea că acestea trec
înainte de comiterea modificărilor în depozitul central.
Alte elaborări ale conceptului au introdus ș i servere de build, care rulează automat
testele unitare periodic, sau chiar după fiecare commit, raportând dezvoltatorului rezultatele.
Utilizarea serverelor de build (care nu rulează neapărat ș i testele unitare) intrase deja în
practica unor echipe din exteriorul comunită ț ii XP. Astăzi, multe organiza ț ii au adoptat CI
fără a adera complet la XP. Pe lângă testele unitare automate, organiza ț iile care utilizează
continuous integration folosesc de regulă un server de build pentru a implementa procesele
continue de aplicare a controlului calită ț ii în general — efort redus, dar aplicat frecvent.
Pe lângă rularea testelor unitare ș i de integrare, asemenea procese rulează ș i alte teste
statice ș i dinamice, măsoa ră ș i analizează performan ț a, extrag ș i formatează documenta ț ia din
codul sursă ș i facilitează procesele manuale de QA. Această aplicare continuă a controlului
calită ț ii urmăre ș te îmbunătă ț irea calită ț ii software-ului ș i reducerea timpului de livrare,
înlocuind practica tradi ț ională de aplicare a controlului calită ț i numai după terminarea tuturor
activită ț ilor de dezvoltare , ceva foarte similar cu ideea ini ț ială a integrării mai frecvente
pentru simplificarea integrării în ansamblul ei, aplicată doar proceselor de QA.

PROCESUL DE DEZVOLTARE

Sunt numeroase aspecte privind test-driven development cum ar fi “Kep it simple,
stupid” (KISS), “You aren't gonna need it” (YAGNI), sau “Single responsibility,
open-closed, Liskov substitution, interface segregation and dependency inversion” (SOLID).
Principiul “KISS” spune că multe sisteme func ț ionează la capacitate maximă când
sunt men ț inute simplu, de cât cu o complexitate mare. De aceea simplitatea ar trebui să fie
ț elul dezvoltării, iar comp lexitatea inutilă ar trebui evitată. Sistemele software sunt între ț inute
de oameni cu capacită ț i limitate de aceea incrementarea complexită ț ii sistemului ar trebui
evitată cu orice pre ț . Bria n Kernighan, dezvolator UNIX, spune ca procesul de debugging
este de doua ori mai greu decât acela de a scrie cod, iar dacă încerci să scrii cod destept,
conform defini ț iei nu e ș ti suficient de inteligent să-i faci debug.
"You aren't gonna need it" este un principiu de extreme programming (XP) care spune
că un programator nu ar trebui să adauge func ț ionalitate decât atunci când este necesară.
Co-fondatorul XP, Ron Jeffries, a spus că e de preferat să introduci func ț ionalitate doar atunci
când este nevoie, niciodata când doar crezi ca ar fi necesară.
SOLID este un acronim introdus de Michael Feathers pentru cele cinci principii ale
programării orientate pe obiecte. Inten ț ia acestor principii, când sunt aplicate impreună, este
ca programatorul să creeze o aplica ț ie de calitate, u ș or de men ț inut în timp.
Concentrându-se doar pe codul necesar trecerii testelor, progamatorul livrează un cod
mai clar ș i mai de calitate . Kent Beck sugerează de asemenea ș i principiul “Fake it until you
make it”.
5

Pentru a folosi concepte avansate de programare cum ar fi design patterns, trebuie să
fie scrise teste specifice pentru acele cazuri. Codul poate să fie mai simplu decât pattern-ul
specificat ș i tot să treacă testele.
Scrierea testelor înaintea func ț ionalită ț ii s-a dovedit a fi f oarte folositoare. Astfel se
asigură că aplica ț ia a fost scrisă pentru testare. Se asigură astfel ș i testarea fiecărui feature. În
plus scrierea testelor înaintea codului duce la o în ț elegere mult mai profundă a specifica ț iilor
clientului de către programator. Primele teste TDD pot nici să nu compileze datorită claselor
nescrise, dar asta nu trebuie să fie un impediment, testele trebuie să fie scrise. Fiecare test
pică ini ț ial, asta înseamnă că sunt bine scrise ș i pot prinde erorile, iar mai apoi se poate trece
la implementarea propriu-zisă a specifica ț iilor. Există o mantră a conceptului de TDD ș i
anume “rosu/verde/refactorizare”. Această provine de la ro ș u-pică, verde-trece. TDD-ul
constă în introducerea continuă de teste care ini ț ial pică, apoi trec, iar la final se trece la
refactorizarea codului, ț inându-se cont că testele să treacă în continuare ș i să nu strice codul
deja existent. Primind rezultatul a ș teptat la fiecare pas, programatorul se simte încrezător ș i
este motivat să continue, crescandu-i productivitatea.
O unitate, în conceptul TDD, reprezintă o clasă sau un grup de metode înrudite,
deseori numite module. Păstrarea unită ț ilor cât se poate de mici aduce o serie de beneficii
precum: reducerea efortului de debugging. Erorile sunt mult mai u ș or de depistat având în
fa ț ă o bucată relativ mică de cod. Al doilea avantaj îl reprezintă faptul că testele mai mici sunt
mai u ș or de citit ș i de în ț eles.

PROCES ÎN CARE ESTE APLICAT TDD

În ț elegerea cerin ț elor din user story, sau a func ț iei pe care se lucrează.
Ro ș u: se crează un test ca re să pice.
1. Progamatorul î ș i imaginează cum ar trebui apelat noul cod ș i astfel scrie testul ca ș i
cum codul ar exista deja.
2. Se crează noul cod de produc ț ie. Se scrie doar codul suficient pentru compilare.
3. Se execută testul. Ar trebui să e ș ueze. Aceasta este o măsură de calibrare pentru ca
dezvoltatorul software să se asigure că testul său apelează codul corect ș i că, codul nu
func ț ionează accid ental. Acesta este un e ș ec semnificativ, iar programatorul se va
a ș tepta ca acesta s ă e ș ueze.
Verde: Se face testul să treacă prin orice mijloc.
1. Se scrie codul de produc ț ie pentru a trece testul respectându-se principiul KISS
2. Unii dezvoltatori consideră utilă hard-codarea valorii a ș teptate pentru verificarea
corectitudinii testului, dar acest lucru depinde de la programator la programator.
3. Dacă codul a fost scris astfel încât testul să treacă conform scenariului, atunci s-a
terminat. Nu trebuie să mai fie scris mai mult cod. Se respecta principiul YAGNI
pentru a evita munca inutilă. Dacă este necesară încă o nouă func ț ionalitate, este
nevoie de un alt test. Se face acest test unic ș i mai apoi se continua.
6

4. Când testul trece, este posibil ca dezvoltatorul să dorească să execute toate testele
până la acest punct pentru a construi încrederea că totul este încă în lucru.
Refactor: Se schimbă codul pentru a elimina duplicarea în proiect ș i pentru a îmbunătă ț i
designul, având grijă în acela ș i timp că toate încercările vor trece.
1. Se elimină duplicarea cauzată de adăugarea noii func ț ionalită ț i.
2. Se fac modificări de proiectare pentru a îmbunătă ț i solu ț ia globală.
3. După fiecare refactorizare, se reiau toate testele pentru a se asigura că totul trece
conform planului.
Se repetă ciclul. Fiecare ciclu trebuie să fie foarte scurt ș i o oră tipică ar trebui să con ț ină mai
multe cicluri Ro ș u / Verd e / Refactor.

BUNE PRACTICI ÎN TDD

Conven ț iile de nu me oferă o mai bună organizare a testelor, care-i ajută pe
dezvoltatori să găsească mult mai u ș or ceea ce au de căutat. Multe tool-uri se a ș teaptă ca
aceste conven ț ii să fie res pectate.
Codul de test trebuie să fie separat de codul dezvoltare. Spre exemplu în Java codul de
test se regăse ș te în directo rul ​ src/test/java ​ ș i codul de dezvoltare se regăse ș te în directorul
src/main/java ​ . Proiectele mai mari pot avea mai multe directoare, însă codul de dezvoltare ș i
cel de test ar trebui să rămână separate.
Testele ar trebui să fie în acela ș i pachet cu clasa pe care o testează, asta ajută
programatorul să le găsească mult mai repede.
O practică des întâlnită este denumirea clasei de test la fel cu clasă pe care o testează,
adăugând sufixul “Test”. De exemplu clasa ​ User ​ ar avea ca ș i clasă de test clasa ​ UserTest ​ .
Numele metodelor ar trebui să fie sugestiv astfel încât să fie u ș or de înteles ce ar
trebui să facă.
7

Dacă un test trece fără a scrie sau a modifica cod, înseamnă că func ț ionalitatea este
deja implementată, sau că testul este scris gre ș it.
De fiecare dată când se adaugă cod func ț ional, testele vechi ar trebui să fie rulate din
nou pentru a se asigura func ț ionalitatea propice a întregului program.
Toate testele trebuie să treacă înainte ca alte teste să fie scrise. Refactorizarea se va
face doar după ce toate testele trec. În general nu este nevoie să se scrie teste noi, ajunge ca
unele teste vechi să fie modificate. Toate testele trebuie să treacă atât înainte cât ș i după
refactorizare.
Fiind rulate destul de des, testele ar trebui să se execute rapid. Dacă ar dura mult,
atunci programatorii nu ar mai folosi sau ar folosi doar un subtest relevant pentru codul
modificat.
Una dintre cele mai des întâlnite gre ș eli făcute de dezvoltatorii software este că
folosesc o clasă de bază care este extinsă de către teste. Acest lucru este gre ș it deoarece se
crează cod duplicat. Se crează confuzie când un programator trebuie să meargă din clasa de
test în clasă părinte, apoi a părintelui său ș i tot a ș a.
Fiecare bucată de cod ar trebui să fie testată, astfel la finalul programului se
calculează un code coverage, care ar trebui să fie cât mai mare posibil. Acest code coverage
se referă la procentul de cod executabil testat prin test case-uri. Programele cu un code
coverage ridicat au ș anse foarte mici de a avea bug-uri comparativ cu cele cu un code
coverage scăzut. Sunt foarte multe metrici de calculare a code coverage-ului unele dintre ele
fiind incluse în programele de testare, oferind procente pe buca ț ile testate.
BENEFICIILE CONCEPTULUI DE TEST-DRIVEN
DEVELOPMENT

Un studiu realizat în 2005 arată că TDD constă în scrierea de mai mult cod, însă
programatorii care scriu mai multe teste sunt de regulă mai productivi. Totu ș i ipotezele legate
de calitatea codului nu au putut fi bine concluzionate.
Programatorii care aplică conceptele TDD în proiecte noi au recunoscut faptul că
folosesc extrem de rar unelte de debugging. Folosit împreună cu un sistem de versionare,
precum Git sau Svn, TDD-ul se dove ș te a fi foarte eficient din punct de vedere al timpului
alocat deoarece trecerea la o versiune anterioară ș i rescrierea codului astfel încât testele să
treacă, dureaza mult mai pu ț in decât procesul de debugging.
TDD oferă posibilitatea să faci pa ș i cât se poate de mici, îi oferă programatorului
ș ansa de a se concentra p e trecerea testelor. Cazurile excep ț ionale precum ș i erorile nu sunt
luate în calcul la început, iar testele pentru aceste cazuri sunt scrise separat. Fiecărei bucată
de cod îi este asignată cel pu ț in un test. Acest lucru oferă programatorilor o încredere mai
mare în codul scris.
În timp ce folosind TDD numărul linilor de cod cre ș te comparativ cu lipsa acestuia,
timpul petrecut în implementare este de regulă mai mic. Numărul mare de teste ajută la
limitarea bug-urilor programului. Testarea devreme a codului ajută la găsirea eventualelor
8

probleme încă din stadiul de dezvoltare. Rezolvarea unui bug în dezvoltare este mult mai
ieftină decât rezolvarea acestuia în produc ț ie. Se merge pe premiza că testele fiind mici pot fi
testate independent ș i apo i integrate la final.

LIMITĂRILE CONCEPTULUI DE TEST-DRIVEN
DEVELOPMENT

Limitările conceptului de TDD sunt că nu oferă suficientă testare în situa ț ile care
necesită aten ț ie specială c um ar fi interac ț iunea cu baza de date, configurări de re ț ea precum
ș i interfa ț a grafică a utilizatorului. Dacă întreaga companie nu cre de în eficien ț a conceptului
de test-driven development atunci manageri vor considera un timp pierdut în scrierea testelor.
Un număr ridicat de teste care trec pot cre ș te încrederea programatorului ș i astfel uita
să mai scrie teste absolut necesare cum ar fi cele de integrare sau de penetrare. Scrierea ș i
men ț inea multor teste con suma foarte mult timp, astfel progamatorii pot fi avertiza ț i în
vederea supratestării.
O arhitectura slabă, un design sărac ș i o sumedenie de teste proaste pot duce la o
schimbare a codului care ar face testele să pice ș i ar necesita repararea individuală a fiecăruia.

TEST-DRIVE-WORK

Conceptul de test-driven development a început să fie adoptat ș i în afara dezvoltării
software, atât în sfera de produc ț ie cât ș i în cea de prestare de serv ici, luând astfel numele de
test-driven work. Astfel există oameni care fac controlul calită ț ii produselor, de regulă
manual, pentru fiecare aspect al muncii lor.

TDD & ADD

Test-driven development este în strânsă legătură, dar diferit cu acceptance test-driven
development (ATDD). TDD este în principal o unealtă a dezvoltatorilor care-i ajută să scrie
unită ț i func ț ionale de cod (func ț ii, clase, module) care îndeplinesc un set de opera ț ii. ATDD
este un tool de comunicare între client, dezvoltator ș i tester care asigură că specifica ț iile sunt
bine definite. TDD necesita testare automată, în timp ce ATDD nu.
Totu ș i automatiza rea ajută la testul de regresie. Testele folosite in TDD deseori pot fi
derivate din testele de ATDD, din moment ce codul implementează o por ț iune din
specifica ț ii. Testele de AT DD ar trebui sa fie citibile de către client, în timp ce testele TDD,
nu ar trebui.
9

TDD & BDD

BDD, behavior-driven development combină practicile din TDD cu cele din ATDD,
axandu-se în mod special pe testarea comportamentului în detrimentul testării func ț ionalită ț ii
sau al implementării. Programele precum Mspec sau Specflow oferă o sintaxă care îi ajută pe
cei care nu ș tiu programa re să definească comportamente pe care mai apoi dezvoltatorii
software să le transforme în teste automate.

SOFTWARE PENTRU TDD

Există o multe de programe sau de framework-uri pentru test-driven development
printre care amintim xUnit frameworks ș i TAP results. Dezvoltatorii software pot folosi
framework-ul de testare numit xUnit, dezvoltat în 1998 pentru a crea ș i a rulă un test. Acest
10

framework oferă testarea codului precum ș i un raport la finalul acesteia. Pe lângă acesta mai
există ș i protocolul Test A nything creat în 1987.
Testele unitare sunt numite astfel deoarce testează câte o unitate în parte. Un modul
complex poate avea o mie de teste unitare în timp ce un modul simplu poate avea doar zece.
Introducând dependin ț e către alte module, testele unitare se transformă în teste de integrare.
Dacă un modul nu se comportă cum trebuie, nu este întotdeauna clar de unde să se înceapă
investigarea după erori.
Când un program se bazează pe o bază de date, un serviciu web sau orice alt proces
ori serviciu, testarea unitară trebuie să fie separată oferind programului mai multă
modularitate.
Folosirea TDD-ului în sisteme complexe necesită o arhitectură modulară, bine pusă
la punct care trebuie să îndeplinească o serie de sarcini. Una din aceste sarcini este să suporte
întregul sistem de testare.

TEST-DRIVEN DATABASE DEVELOPMENT

O întrebare foarte frecventă în comunitatea dezvoltatorilor agile este: “poate oare
TDD să func ț ioneze ș i integrat cu baze de date?” Cei 5 pa ș i din cartea “Test Driven
Development by Example” nu ofera exemple pentru limbaje de programare de nivel înalt
precum Java sau C#, însă acestea sunt mediile în care TDD este des folosit. De aceea se pune
întrebarea de ce nu ar merge scris un test înainte de a se face o interogare într-o bază de date.
Singura problemă este că aplica ț iile precum DBUnit sunt încă la început de drum. În
comunită ț ile de baze de d ate testarea unitara nu este prea bine primită, însă în viitor acest
lucru se va schimba. Conceptul de dezvoltare evolutivă este relativ nou pentru profesioni ș tii
în baze de date ș i de acee a aplicarea metodologiei de TDD stagnează.
Majoritatea oamenilor care lucrează cu date preferă modelul orientat pe modelare, nu
pe testare. Un motiv pentru acest lucru ar putea fi faptul că TDD este un concept relativ nou
fa ț ă de prelucrarea datelo r, iar cei care lucrează cu baze de date preferea gândirea vizuală,
bazată pe modelare.

DOCUMENTA Ț IA DESPRE TDD

Din nefericire, mul ț i programatori nu citesc documenta ț iile pentru aplica ț ii, ei preferă
să lucreze cu codul, iar acest lucru nu este rău de loc. Când încearcă să în ț eleagă o clasă sau o
metodă, majoritatea programatorilor se vor uita după exemple în care sunt folosite.
Testele unitare bine scrise exact asta fac, oferă specifica ț ii despre func ț ionalitatea
codului ș i ca rezultat teste le unitare devin por ț iuni semnificative din documenta ț iile tehnice.
Testele de acceptan ț ă def inesc ce vrea clientul de la aplica ț ie, specificând cerin ț ele
11

obligatorii. Testele de regresie definesc specifica ț ile executabile. Testele nu sunt suficient de
bine documentate ș i s-ar p utea de multe ori să mai fie nevoie de documenta ț ii suplimentare.

CONCLUZII

Test-driven development este o tehnică avansată care folose ș te teste unitare pentru a
realiza produse software. Întregul proces pare să fie complicat pentru juniori, însă după ce se
obi ș nuiesc, dezvoltatorii software vor scrie cod de calitate mai bună, aplica ț ia va fi mai u ș or
de între ț inut ș i va fi mereu testată. TDD folosit împreună cu ATD D ș i BDD oferă aplica ț iei
teste unitare ș i func ț ionale.
Folosind metodologia TDD, un programator va scrie cod doar pentru ce este necesar,
se va concentra mai mult pe task, va gândi din exterior ș i nu în ultimul rând va deveni un
programator mai bun.
Să nu uităm că testarea este un proces inevitabil în dezvoltarea software, însă atunci
când deadline-urile bat la u ș ă, ea este rapid dată la o parte.
Această lucrare subliniază principalele caracteristici ale acestei metodologii, însă
există numeroase căr ț i pentru aprofundare ​ a acestui subiect.

BIBLIOGRAFIE

Wikipedia (2017) – “Test-driven development”, disponibil online la
https://en.wikipedia.org/wiki/Test-driven_development
Technology Conversations (2013)-”Test Driven Development (TDD): Best Practices
Using Java Examples”, disponibil online la
https://technologyconversations.com/2013/12/24/test-driven-development-tdd-best-practices-
using-java-examples-2/
Technology Conversations (2014)-”Test Driven Development (TDD): Example
Walkthrough”, disponibil online la
https://technologyconversations.com/2013/12/20/test-driven-development-tdd-example-walkt
hrough/
AgileData(2016)-”Introduction to Test Driven Development (TDD)”, disponibil
online la ​ http://agiledata.org/essays/tdd.html
TutorilasPoint(2017)-”Test Driven Development”, disponibil online la
https://www.tutorialspoint.com/software_testing_dictionary/test_driven_development.htm
MSDN.Microsoft(2006)-”Guidelines for Test-Driven Development”, disponibil
online la ​ https://msdn.microsoft.com/en-us/library/aa730844(v=vs.80).aspx

12