Test Driven Development

Mazilu Liviu-Andrei, ISS2

Test Driven Development (TDD) este o abordare diferită în dezvoltarea

sistemelor software ce constă în iteraţii mici de dezvoltare unde mai întâi sunt scrise
teste pentru a testa o nouă funcţionalitate ce urmează a fi implementată. Codul necesar
ce va trebui sa treacă testul este implementat după scrierea testului şi apoi testat
folosind acel test. În continuare defectele sunt reparate şi componentele sunt
refactorizate pentru a întruni schimbările. În această abordare, scrierea codului se face
într-o manieră greedy : se scrie suficient cod pentru a trece testul, iar un ciclu de
dezvoltare TDD reprezintă de cele mai multe ori scrierea a una sau cel mult puţine
metode,funcţii sau obiecte ce vor fi apelate de noul test.

Test Driven Development reprezintă amalgamul a două tehnici de programare:

Test First Development (TFD) şi Refactorizare. Privind prima tehnică, TFD propune ca
înainte de a se scrie cod funcţional mai întâi se scrie un mic test pentru a testa
rezultatul acelui cod care încă nu este scris. Pentru a realiza aceasta un developer
trebuie să intre în mindset-ul potrivit conform lui David West, “Object thinking”: ,,un
bun developer trebuie să înveţe să se concentreze pe spaţiul problemei şi nu să se
arunce direct in spaţiul soluţiilor”.

Paşii TFD sunt ilustraţi sub forma unor

diagrame UML în figura 1. Primul pas este adaugarea
rapidă a unui test, care să conţină destul cod încât
testul să nu fie trecut. În pasul următor se rulează
testele, de obicei întreaga suită de teste chiar dacă
în unele cazuri, pentru a mări viteza se poate rula
doar o submulţime de teste relavantă la ultima
modificare, pentru a se asigura că întradevar
ultimul test eşuează. Apoi se modifică codul
funcţional pentru a se asigură că va trece acel test.
Următorul pas este acela de a rula încă o dată
testele. Dacă vor eşua iar, codul funcţional va fi
modificat în continuare şi va urma retestarea. Odată
ce testele reuşesc se reia procesul de scriere de noi
teste(mai întâi poate fi necesară refactorizarea
posibilelor duplicâri de cod din design, transformând
TFD în TDD. Figura 1

1
 Urmărind această idee se poate afirma că TDD= Refactorizare + TFD. TDD
oferă o perspectivă complet nouă faţă de dezvoltarea clasică de software. Când
urmează a fi implementată o nouă funcţionalitate, prima întrebare care este pusă este
acea dacă design-ul existent este cel mai bun design care să permită implementarea
acelei functionalităţi. Dacă acest lucru este adevărat atunci se continuă folosind o
abordare TFD. În caz contrar va urma o refactorizare locală pentru a schimba acea
porţiune din design afectată de noua funcţionalitate, pentru a permite adăugarea ei cu
uşurinţă. Rezultatul va fi aceala de a îmbunătăţi calitatea design-ului, fiind mai uşor de
lucrat cu el pe viitor.

În practică folosind o abordare TDD, ordinea este inversată. Dacă până la TDD
mai întâi se scria cod functţional urmat de cod de test pentru a testa acel cod
funcţional(existând posiblitatea ca acel cod de test să nu existe), acum se va scrie în
primă fază codul de test, urmat de codul funcţional. În plus, acest lucru se va realiza în
paşi foarte mici, testându-se bucăţi mici de cod funcţional.

Un developer ce scrie cod în această manieră va refuza să scrie cod funcţional

până ce nu va exista un test care să eşueze din cauza că acea funcţie încă nu este
prezentă. Odată ce testul există, acel developer va construi funcţionalitatea necesară
pentru ca suita de teste să fie trecută cu succes. Developerul care scrie cod în aceasta
manieră necesită un nivel ridicat de disciplină, pentru că este uşor să se "greşească" şi
să se scrie cod funcţional înaintea codului de test. De aceea TDD se încadrează perfect
în contextul oferit de eXtreme Programming (XP), ceea ce presupune lucrul în perechi,
deoarece perechea developerului îl va ajuta să respecte această convenţie.

Împărţind această teorie în paşi simpli, logici obţinem următoarea iteraţie:

1. Test: Scrie un test mic (unul singur, nu mai multe)

2. Compilează: Compilează codul şi fă ca testul să eşueze.
3. Eşuează: rularea testului va duce la eşuarea lui (ROŞU)
4. Cod: scrie codul funcţional, suficient ca testul să treacă, nu mai mult
5. Trece: rulează testul, ar trebui să treacă. Dacă nu atunci revină la pasul 4. Dacă
trece, codul primeşte VERDE (factorul roşu-verde)
6. Refactorizare: refactorizarea codului scris până acum(atât de test cât şi funcţional)
7. Trece iar. Dacă nu va trece revină la pasul 4.
8. Repetă: Se intoarce la pasul 1 şi se repetă până când se ajunge la funcţionalitatea
completă dorită.

TDD este considerată o practică agilă, prin urmare multă lume nu deţine
cunoştinţe relevante despre aceasta, sau în cel mai rău caz cei ce se află la început,

2
 cred că TDD reprezintă scrierea de teste automate pentru cod sau chiar mai rău, că
TDD este o modalitate de testare a codului şi nu de scriere a sa.

De aici apar o serie de misconcepţii/confuzii:

1. TDD este o practică pentru testeri
O mare parte din confuzie este cauzată de nume: Test Driven Development, care
pentru mulţi developeri poate însemna o metodă de scrie a testelor automate, o
practică care ar trebuie să facă parte din responsabilităţile managerului de QA.

2. Prezenţa testelor automate reprezintă o abordare TDD

Cei care sunt la început cu practicile agile de dezvoltare, au tendinţa de a crede că
dacă au teste automate care acoperă parţial sau total codul, înseamna că practică TDD.
De fapt au dreptate, numai dacă acele teste au fost construite înaintea codului şi
nu după. Dacă testele nu au influenţat procesul de dezvoltare a sofware-ului atunci nu
este TDD, este doar prezenţa testelor automate, care oricum este un lucru bun.

Trecând peste aceste confuzii, odată ce un developer decide să abordeze

dezvoltarea de software folosind TDD aceast automat va avea nevoie de o serie de tool-
uri pentru a face acest lucru posibil.
O presupunere imediată este prezenţa unui framework pentru unit-testing.
Majoritatea developerilor optează pentru suita de tool-uri open source din familia xUnit
cum ar fi JUnit sau VBUnit, totodată existând şi opţiuni comerciale viabile.

Fără un astfel
de tool TDD este
practic imposibil.
Figura 2 prezintă o
diagramă cu stări UML
care descrie modul în
care se lucrează cu un
astfel de tool.

Figura 2
Pentru cei ce
dezvoltă aplicaţii. NET există o serie de tool-uri care să le uşureze dezvoltarea folosind
TDD, tool-uri ce pot fi/sunt integrate în Microsoft Visual Studio.
În alegerea framework-ului de testare trebuie urmărită uşurinţa cu care se poate
integra în workflow-ul fiecărui developer. Următoarele opţiuni sunt disponibile:
1. MSTest
Dacă folosiţi Visual Studio, ediţiile Professional sau Team nu trebuie să căutaţi
prea departe. Suport pentru framework-ul de testare nativ creat de Microsoft este
disponibil direct din IDE. MSTest este un framework de unit-testing cu sintaxa foarte
asemănătoare cu NUnit, dar este disponibil doar pentru ediţiile Pro şi Team, deci va fi
nevoie de o soluşie terţă dacă foloseşti ediţiile Standard sau Express.

3
 2. NUnit
NUnit reprezintă framework-ul de bază pentru .Net, şi probabil framework-ul de
care majoritatea a auzit sau folosit. Deşi acest tool nu vine cu mai nici un suport din
cadrul IDE-ului, runner-ul şi comandline-ul standalone reprezintă o bază foarte
puternică pentru mulţi practicanţi TDD.
3. MbUnit
MbUnit a fost, pentru o perioadă foarte lungă, singura variantă reală la NUnit.
Sintaxa seamănă cu cea a MSTest sau NUnit dar are o serie de abilităţi care depăşesc
celelalte framework-uri.
RowTest a fost pentru foarte mult timp motivul pentru care lumea a ales MbUnit
peste celelalte framework-uri. Totodată este legat în Gallio, un runner de teste care va
rula teste în majoritatea framework-urilor.
4. XUnit.net
XUnit.net a apărut recent în lista de framework-uri de unit-testing pentru .NET, şi
este dorit a fi mai mult decât un framework pentru unit testing. Este foarte controversat
şi se depărtează cel mai mult de framework-urile prezentate anterior. Sintaxa şi modul
de scriere a testelor este radical diferită, şi necesită citirea integrală a deciziilor luate de
designerii framework-ului pentru a o înţelege.

Pe partea de refactorizare developerii .NET pot folosi tool-uri precum ReSharpher

sau Refactor! Pro, amândouă oferind un ajutor în plus la crearea de metode stub,
mărind puterea IntelliSense-ului şi ajutând developerul să refactorizeze codul astel încât
acesta să rămână cât se poate de curat şi impactul asupra viitoarelor schimbări scăzut.

Beneficii ale TDD:

- developerii primesc un feedback aproape imediat asupra componentelor la
care lucrează şi sunt testate. Timpul de rezolvare a unui defect este mult mai mic decât
în cazul altor abordări unde codul este testat la distanţa de câteva zile/săptămâni, timp
în care developer-ul a trecut la alte module.
- implementarea are şanse mai mari să îndeplinească cerinţele iniţiale definite de
client. Cazurile de test sunt uşor generate şi reflectă cu acurateţe specificaţiile
funcţionale fără interferenţe cauzate de constrângerile sau limitările design-ului
arhitecturii. Această abordare garantează în oarecare măsură ca versiunea finală va
îndeplini cerinţele pieţii sau ale clientului.
- metodologia previne apariţia componentelor defectuoase în produs. Cazurile de
test definesc exact setul de funcţionalităţi necesare. Astfel se poate identifica mai uşor
codul redundant şi se pot detecta şi încheia implementările inutile.
- TDD poate duce la cod flexibil, modularizat şi extensibil. Metodologia cere
developer-ului să se gândească la software în termeni de unităţi mici care pot fi scrise şi
testate separat şi integrate împreuna mai tarziu.

Bibliografie:
1. Test-Driven Development By Example, Kent Beck, 2002 Addison Wesley

4
 2. Test-Driven Development: A Practical Guide, David Astels, Prentice Hall PTR
3. http://www.agiledata.org/essays/tdd.html
4. http://www.daniweb.com/tutorials/tutorial42956.html
5. http://bloggingabout.net/blogs/danbunea/archive/2005/12/07/10480.aspx
6. http://debuggable.com/posts/introduction-to-test-driven-development-tdd-part-
1:480f4dfd-e8f4-4a82-923c-4625cbdd56cb
7. http://www.pnexpert.com/files/Test_Driven_Development.pdf
8. http://www.geekzone.co.nz/vs2008/6187