TDD - timp pierdut în plus?

TDD - timp pierdut în plus? =========================== joi, 21 octombrie 2010 Înainte de a intra în ritmul TDD, sau privind dintr-o parte, s-ar părea că scrierea testelor înainte de a scrie codul propriuzis este mai mult o pierdere de timp. E destul de clar de ce pare aşa: scrii cam de două ori mai mult cod. Dar, asta este pe termen scurt. Dacă vrei să vezi cum lucrează o anumită funcţie, sau să experimentezi cu un framework, sau să încerci un nou limbaj de programare, ceeea ce în termeni de Extreme Programming se numeşte "spike", atunci da, nu are rost să faci TDD-ul decît pentru exerciţiu. Dacă vrei să faci ceva care ar putea dura zile sau săptămîni, atunci TDD-ul se răscumpără, cel puţin. Şi ca timp de lucru, şi ca calitate a rezultatului final. Dacă scrii teste, nu trebuie să verifici la fiecare nouă modificare dacă nu cumva s-a dărîmat altceva pe undeva. Dacă peste două luni trebuie să faci o schimbare în cod, atunci nici nu prea mai ţii minte care şi de ce depinde ca să poţi verifica manual. Şi cu cît e mai mare proiectul cu atît rentabilitatea TDD-ului creşte, pentru că verificare manuală ia din ce în ce mai mult timp, aici el se răscumăra ca timp, şi, de la o vreme încetezi să mai testezi anumite părţi pentru că, deja nu mai e practic să testezi manual o lună de lucru de cod, şi atunci, în speranţa că totuşi, poate nu s-a stricat nimic. Aici apar problemele de calitate. Dezvoltarea şi fixarea de bug-uri sunt două momente foarte clare unde este practic necesară testarea automatizată. Un alt moment este refactorizarea. Cînd pe parcursul dezvoltării ne dăm seama de un mod mai optim de a structura codul şi am vrea să-l reorganizăm pentru a-l simplifica, sau pentru a-l optimiza cumva, e destul de dificil să faci asta fără să ai o acoperire bună de teste automatizate. Şi dacă nu poţi refactoriza, programul ajunge să fie din ce în ce mai greoi, şi de la o vreme apare dorinţa să-l scoţi cumva la un capăt şi să nu mai ai de a face cu el. Refactorizarea este partea de *design* a TDD-ului, de fapt Test Driven *Design*, e o altă descifrare a acestui acronim, şi prin design aici se are în vedere schimbările la nivel înalt pe care le putem face în cod treptat, pe măsură ce înţelegem problema mai bine şi pe măsură ce învăţăm să folosim limbajul mai bine sau schimbări de nivel înalt care apar din alte considerente pe parcursul dezvoltării.