Articole
Teste, teste … teste PHPUnit!
Un exemplu practic despre cum vă pot ajuta testele unitare ca profesionist
Ca dezvoltator, vă întâlniți cu multe moduri de a scrie cod și cu multe idei. Unele sunt reușite și vă uimesc prin cât de elegantă și de eficientă este soluția implementată, dar altele vă fac să vă întrebați cum poate un dezvoltator să scrie un cod atât de prost.
De multe ori, totul este acoperit de expresii precum „merge, nu?” sau „intră clienții și banii, deci totul e în regulă”. Da, este 100% adevărat, dar, ca product owner sau proprietar de afacere, trebuie să înțelegeți că acesta este ceea ce se numește un produs mediocru, dacă nu chiar mai rău.
Recent, un client mi-a pus la dispoziție codul său pentru a implementa funcționalități noi, iar eu am descoperit o aplicație Laravel cu un fișier SQL :). Probabil ați ghicit … migrațiile nu erau la zi cu baza de date, iar fișierul SQL era sursa „adevărului”.
Dacă vă întrebați de ce sau cum este posibil așa ceva, răspunsul e foarte simplu: așa arată viața de dezvoltator, plină de provocări. Îmi amintesc că, pe când eram dezvoltator junior, mă speriau astfel de situații și probabil l-aș fi lăsat pe client așa. Cu timpul am învățat să „îmi asum dezordinea” (own the mess). Acest proces este descris cel mai bine în cartea „Clean Code” de Robert C. Martin (Uncle Bob).
Revenind la client, eram pe punctul de a-i spune „asta e varză, trebuie să plătiți mai mult” sau „nu mă apuc de așa ceva”, pentru că vă puteți imagina că nici în restul codului nu putea fi vorba de ceva precum PSR-2. Din perspectiva mea, acesta este minimul decent pe care îl poate face un dezvoltator. Oricum, mi-am „asumat dezordinea” și mi-am continuat sarcina. M-am uitat în fișierul SQL, am adus toate migrațiile la un flux normal și am mers mai departe.
Poate vă întrebați de ce am făcut asta? Răspunsul meu este că nu mă tem de „codul legacy” sau de „codul spaghetti”. De obicei găsesc adevărate bijuterii în acest tip de cod, iar ca rezultat al efortului meu am implementat teste PHPUnit.
Acesta este un alt subiect: de ce ar trebui măcar să încercați să introduceți teste în proiect, iar dacă aveți un proiect nou, să folosiți pur și simplu TDD. Știu că necesită foarte mult timp și este foarte stresant, dar beneficiile pe termen lung sunt uriașe. Stabilitatea și fiabilitatea software-ului vor fi mereu acolo! Dacă testele sunt scrise bine și testați codul corect, sunteți aproape de a deveni un dezvoltator mai bun decât majoritatea.
De multe ori, totul este acoperit de expresii precum „merge, nu?” sau „intră clienții și banii, deci totul e în regulă”. Da, este 100% adevărat, dar, ca product owner sau proprietar de afacere, trebuie să înțelegeți că acesta este ceea ce se numește un produs mediocru, dacă nu chiar mai rău.
Recent, un client mi-a pus la dispoziție codul său pentru a implementa funcționalități noi, iar eu am descoperit o aplicație Laravel cu un fișier SQL :). Probabil ați ghicit … migrațiile nu erau la zi cu baza de date, iar fișierul SQL era sursa „adevărului”.
Dacă vă întrebați de ce sau cum este posibil așa ceva, răspunsul e foarte simplu: așa arată viața de dezvoltator, plină de provocări. Îmi amintesc că, pe când eram dezvoltator junior, mă speriau astfel de situații și probabil l-aș fi lăsat pe client așa. Cu timpul am învățat să „îmi asum dezordinea” (own the mess). Acest proces este descris cel mai bine în cartea „Clean Code” de Robert C. Martin (Uncle Bob).
Revenind la client, eram pe punctul de a-i spune „asta e varză, trebuie să plătiți mai mult” sau „nu mă apuc de așa ceva”, pentru că vă puteți imagina că nici în restul codului nu putea fi vorba de ceva precum PSR-2. Din perspectiva mea, acesta este minimul decent pe care îl poate face un dezvoltator. Oricum, mi-am „asumat dezordinea” și mi-am continuat sarcina. M-am uitat în fișierul SQL, am adus toate migrațiile la un flux normal și am mers mai departe.
Poate vă întrebați de ce am făcut asta? Răspunsul meu este că nu mă tem de „codul legacy” sau de „codul spaghetti”. De obicei găsesc adevărate bijuterii în acest tip de cod, iar ca rezultat al efortului meu am implementat teste PHPUnit.
Acesta este un alt subiect: de ce ar trebui măcar să încercați să introduceți teste în proiect, iar dacă aveți un proiect nou, să folosiți pur și simplu TDD. Știu că necesită foarte mult timp și este foarte stresant, dar beneficiile pe termen lung sunt uriașe. Stabilitatea și fiabilitatea software-ului vor fi mereu acolo! Dacă testele sunt scrise bine și testați codul corect, sunteți aproape de a deveni un dezvoltator mai bun decât majoritatea.