Care-i treaba cu TDD-ul

duminică, 10 octombrie 2010, 10 al lunii a 10-a a anului 2010 :)

Ce m-a apucat? Păi hai să vă povestesc pentru ce mi-a trebuit mie sucitura asta cu TDD-ul. O să încep cu partea uşoară, care se vede cu ochiul liber: testarea automatizată.

De obicei, după vreo două săptămîni de lucru la un proiect, se adună destul de multă funcţionalitate şi devine din ce în ce mai greu să verifici tot după fiecare modificare, mai ales dacă se întîmplă schimbări care afectează mai multe părţi ale aplicaţiei. Şi dacă ai destul curaj (?) să nu verifici tot, stă în subconştient un vierme care te roade tot zicînd “oare nu s-o fi stricat ceva pe undeva?”. Şi dacă mai e o aplicaţie care e deja în producţie şi se lucrează la modificări, atunci pericolul, şi repectiv îngrijorarea, e şi mai mare. Şi nu ştiu cum pe voi, dar pe mine tare mă consumă îngrijorarea asta. E o stare de stres, şi stresul nu numai că îţi mănîncă o grămadă de energie, dar te şi împiedică să gîndeşti bine, nemaivorbind creativ.

Şi, dacă mă duce capul cum să pun la punct un mecanism de testare automatizată, cum povesteam în articolul precedent, atunci dorm cu mult mai liniştit: după fiecare modificare oricît de mică sau oricît de mare, pot verifica foarte repede dacă mai merge totul cum mergea.

Evident nu pot scrie din start setul ideal de verificări, dar, e OK, imediat cum detectez o scăpare, scriu repejor un test şi gata! iar sunt la linia de plutire. Adică orice problemă mă deranjează doar o singură dată.

Deci e foarte clar că testarea automatizată îţi uşurează viaţa de programator. Kent Beck însă a mers mai departe de atît şi a inventat TDD-ul: Test Driven Development. Şi şmecheria consta în aceea că înainte de a scrie orice bucăţică de cod, să scrii un test care verifică că codul respectiv (viitor) face ce trebuie să facă. Şi una dintre esenţele acestei abordări este că îţi clarifici foarte bine şi foarte exact ce vrei să faci. Mie de exemplu mi s-a întîmplat de foarte multe ori să încep să programez ceva fără să am o idee clară despre ce anume şi cum urmează să funcţioneze mecanismul respectiv. Desigur şi asta e normal la stadiul de explorare, partea în care doar pipăi şi încerci să-ţi faci o impresie despre ce şi cum se poate face, de exemplu cînd încerci o tehnologie nouă, dar, cînd scrii cod care mai tîrziu se duce în producţie aatunci e mai bine să ştii ce vrei să faci. :)

O altă chestie bună care rezultă din TDD e că de la bun început te gîndeşti cum să scrii codul ca să-l poţi verifica. Asta e elementar de înţeles şi de închipuit atunci cînd te gîndeşti la funcţii şi la clase. Un exemplu banal: vrei o funcţie care să-ţi spună cîte zile în urmă e o anumită dată. Dacă funcţia s-ar numi daysSince testul scris cu QUnit ar arăta cam aşa:

După definirea testului, un pas important în TDD e să-l rulăm să vedem că nu trece şi să ne asigurăm că funcţia nu este deja implementată de altcineva. Deci executăm testele: roşu. Bun!

Acum ştim că funcţia ar trebui să ne întoarcă 1 dacă i-am da ca argument data de ieri. În cazuri de complexitate mai mare, nenea Kent ar merge pe calea “fake it till you make it” implementînd funcţia daysSince cam aşa:

Pare anectodic, dar asta respectă principiul “the simplest thing that could possibly work”, şi dacă precăutăm cazul concret pe care-l avem în test, atunci, funcţia face suficient cît să-l treacă. Sună a braşoavă, dar, aveţi răbdare, toate se leagă mai tîrziu foarte bine. ;) Pe deasupra, dacă avem vreo problemă cu implementarea asta, avem la dispoziţie următorul pas din ciclul TDD: refactorizarea. Acum cel mai important lucru de pe lume e să avem verde la teste.

Dar cum la noi funcţia e destul de simplă ca algoritm, o să încercăm să scriem o implementarea reală din prima. Cel mai simplu algoritm care-mi vine în minte e să transform data care vine ca argument în timestamp, transform şi data curentă în timestamp, fac scăderea, împart la numărul de milisecunde dintr-o zi, şi rotunjesc aritmetic:

Gata. Dacă astea dunt cerinţele, asta e implementarea. Cînd apar alte cerinţe, scriu alte teste şi iar sunt asigurat că funcţia face ce trebuie să facă, iar dacă nu face, o să aflu imediat.

Într-adevăr, e una să testezi o funcţie, şi alta e să încerci să testezi codul JavaScript care există de obicei în aplicaţiile web, sau cum să-l scrii testabil. Hai să vedem. Vreau să verific că atunci cînd dau click pe un buton mi se afişeză nişte informaţie suplimentară despre ceva.

Nu e complicat deloc cînd merge vorba de chestii sincrone ca aceasta. Treaba e un pic mai delicată cînd avem chestii asincrone de genul la AJAX, de exemplu dacă detaliile care trebuei afişate, trebuie să le încarc de pe server şi această abordare nu mai merge pentru că după ce simulez un click pe buton, datele încă nu sunt încărcate. Pentru a testa chestii asincrone QUnit are teste asincrone.

Aici se zice aşa: cînd div.moreDetails o să-mi zică că s-au încărcat datele, atunci o să verific dacă s-au afişat. Pentru ca asta să funcţioneze, în aplicaţie trebuie să declanşăm evenimentul loaded pe div-ul respectiv, şi asta se face elementar cu jQuery:

În aceeaşi manieră se pot testa mecanisme asincrone de orice complexitate.

Pe scurt (mi se termină timpul ;)) TDD-ul ne ghidează spre a scrie cod testabil, ceea ce duce la o mult mai uşoară automatizare a testelor.