Testing & TDD (Test Driven Development)

[•Mishu91]

Am o intrebare adresata in special celor care au lucrat in companiile mari, dar nu numai. In ce masura se face TDD la nivelul cel mai inalt? Este o tehnica asa de des folosita, precum se aude?

Iar alta intrebare ar fi, cat de riguroase se fac testele automate? Intreb asta, pentru ca fiind de multe ori presat de timp eu personal nu testez foarte mult bucatile de cod despre care sunt "sigur", sau eventual fac cateva teste "de mana".

[•padreati]

Salut, am sa incerc eu un raspuns care este mai mult o opinie personala decat ce se intampla acum in industrie.
Raspunsul pe foarte scurt este ca orice mod de organizare a activitatilor de dezvoltare e bun atata vreme cat acest mod este privit ca un instrument si nu ca un scop in sine, atata vreme cat nu se face abuz (al doilea motiv deriva cumva din primul).

In opinia mea toate chestiile de genul TDD, agile, sprint, scrum, kanban sunt niste mizerii. Ele in sine nu sunt asa si toate au pornit de la o idee buna, de la un scop nobil. Insa dupa cateva succese mai mult sau mai putin locale s-a incercat de fiecare data extrapolarea folosirii acestora la nivel mare unde au esuat de obicei lamentabil. Din pacate insa ele isi mai au utilitatea inca in practica din cauza nivelului scazut de pregatire al programatorului. Sa ma explic, drept pentru care am sa ma imitez mai precis la TDD.

A aplica TDD ca la carte (acum mai depinde si care care e citita), nu e un lucru rau in sine, cum de altfel nici neaplicarea lui. Orice forma de organizare a codului si efortului de programare este o chestie buna in principiu atata vreme cat nu ajung sa devina scopuri. De exemplu atata vreme cat nu ajungi sa iti spui chestii de genul: "ne-am propus 78% test overage si avem numai 70%". Intr-un asemenea scop, chiar si prezenta unei cifre este idioata in sine. E o vorba care spune foarte clar, si pe care am trait-o pe propria piele care zice ca "ceea ce doresti aceea vei obtine". In cazul nostru vei obtine probabil un "78% test coverage" si asta e tot. Nu vei obtine cod mai bun, mai stabil sau mai clar. Ci pur si simplu un procent. Motivul principal esre acela ca depinde foarte mult ce tip de cod scrii. Altfel spus una este sa scrii un arbore inversat in care sa tii termeni pe disc si sa ii cauti in diverse moduri si alta e sa scrii o aplicatie care trage ceva din db si arunca undeva pe ecran acele lucruri. In primul caz discutam de un algoritm, de un anumit contract intre cel care implementeaza acel algoritm si cel care il foloseste. In al doilea discutam de punerea cap la cap de cele mai multe ori a unor obiecte cu alte obiecte in cadrul unui framework. Acesta e primul motiv pentru care propunerea unei cifre pentru coverage e absolut idioata - nu poti masura intr-un mod util.

Un al doilea motiv este cat de bine este progatit este programatorul. Exista o mare foame de programatori in ziua de astazi, foame care se datoreaza, in propria mea opinie, nivelului din ce in ce mai scazut al progatirii din scoala si de acceptare la angajare din partea firmelor. De o buna vreme incoace a inceput sa se confunde programarea cu manuirea in cunostinta de cauza a unui limbaj de programare (unul, mai multe, aici intra si tehnologiile). O alta vorba zice ca un programator prost creaza alte doua locuri de munca. Si nu e departe de adevar. De aici, cred eu, si inflatia aceasta de instrumente prin care incerci sa tii lucrurile sub control.

Eu am ajuns la concluzia ca e bun pentru cateva chestii punctuale. Cand ai de scris o componenta/algoritm care trebuie sa faca ceva anume si vrei sa te asiguri ca face ce ar trebui sa faca si ca pe viitor modificarile sunt compatibile semantic. Mai sunt bune pentru a arata in practica cum anume sa se foloseasca un anumit lucru (nu ca scop in sine de documentare, ci pentru a pune cap la cap ceea ce intr-o documentare este prea verbose). Pentru a verifica anumite compatibilitati sau criterii de performanta atunci cand este posibil. Este probabil sa mai fie si alte motive, acestea sunt cele pe care le-am intalnit cel mai des.

Si ajungem in fapt la ideea centrala. Dijkstra zice ca cel mai important lucru este intelectual managebility. Adica asa cum inteleg eu, sa stapanesti/controlezi din punct de vedere al intelegerii propriul cod (al tau sau cod al unui grup). Daca cineva ar citi atent aceste carti despre TDD, Agile etc si-ar da seama ca ele au avut succes numai cand programatori erau bine pregatiti. Ce numesc eu un programator bine pregatit este un programator care isi pune intrebari, lucru care mi se pare esential. Complet diferit fata de specia care se apuca sa faca ce i se pare bun, in cea mai mare viteza daca se poate. Concluzionand si rezumandu-ma la propria mea experienta de lucruri in companii diverse (sunt peste 15 ani de cand am vazut tot soiul de chestii), echipele bune isi fac propriile reguli, care de cele mai multe ori seamana cu cele din carti. Echipele slabe, hoardele, isi propun sa aplice by the book, isi antreneaza angajatii sa aiba centuri negre in scrum, kanban si sfarsesc tot prin a avea un cod pe care nimeni nu doreste sa se uite, primii fiind ei. Cred ca ar trebui fiecare sa se concentreze in a isi exersa propria judecata, in a pune la indoiala orice, in a incerca sa faca el lucrurile si mai apoi orice forma de organizare a codului sau a programarii poate fi buna.

PS: Nu am avut ocazia sa lucrez pentru marii din domeniu, Google, Facebook et co, dar cred ca lucrurile stau cam asa si acolo.