La final zice:
I’ll note that my poor experiences with testing were not the result of writing deliberately bad tests and being unhappy with the result.
De aici deduc ca are “poor experiences with testing”, deci tot articolul e invalidat de chestia asta.
Dureaza ani (1-2-3+) de “antrenament” sa devii bun la scris teste (sau la TDD). Majoritatea doar ating suprafata si apoi se plang ca “testele sunt inutile, fac mai mult rau decat bine, e un chin sa le mentinem, etc.”. Dupa cateva zile de scris teste renunta. Apoi revin dupa 1 an si iar incearca pentru cateva zile sa scrie teste. Trec ani buni si programatorul respectiv are tot 0 experienta la TDD.
Si mai e o alta chestie: cand scrii testele? Dupa ce ai scris codul? Ala nu e TDD. Apoi: cine scrie testele? Nu cumva pui un coleg mai junior sau nou venit in echipa sa scrie teste pentru codul tau? Nici ala nu e TDD.
TDD inseamna sa scrii testele inainte de a scrie codul. Altfel e orice, dar nu e TDD.
Vorbim de teste unitare, nu de altfel de teste. Testele unitare sunt utile pentru programatori si pentru regresie si refactoring, nu pentru E2E/integration testing sau altceva.
In lipsa testelor unitare, cum te asiguri tu, ca programator ca daca schimbi ceva in cod peste 1 an, nu strici in alta parte? Sau cum faci refactoring peste 1 an daca nu ai nicio posibilitate sa te asiguri ca nu ai stricat sistemul in 10 locuri in urma refactorizarii?
In perioada cat am lucrat cu node.js si npm testele (cu mocha+chai) chiar erau o aditie misto la dev. E misto sa vezi greenchecks curgand pe terminal dupa o schimbare de cod.
Dar uite ca nu-i posibil sa faci TDD oriunde sau oricand. Cand sunt pe gamedev habar n-am cum as putea (sau daca se poate) sa fac TDD.
Si in 99% din cazuri nu se merita - de obicei codul la jocuri tre’ sa mearga odata si dupa aia pa (era un articol pe tema asta da’ nu mai stiu unde sa-l gasesc :P).
Mai sunt si alte considerente dar nu le enumerez acum.
Ma gandesc ca poate se aplica si in alte arii ale programarii unde TDD pur si simplu nu renteaza.
Daca e o firma cu 2 - 3 programatori si bugete de zeci/sute de mii de euro, nu ai cum.
Daca e un proiect cu zeci de programatori, bugete de zeci de milioane de euro, da.
Altfel spus, daca faci economie de bani implementant teste, da, merita. Daca o faci de dragul artei si dezvoltatorii pierd mai mult timp scriind testele decat timpul necesar repararii defectelor care mai apar, atunci nu merita.
TDD nu se face de dragul artei, ci pentru a asigura o anumita calitate a codului scris, precum si pentru a avea niste “dovezi” cum ca codul scris face ceea ce spui tu ca face. Si ca va face ceea ce spui tu ca face si peste 1 luna, dar si peste 3 ani.
Suntem programatori si lucram cu date, nu oameni de comunicare care lucreaza cu vorbe. Asa ca ma astept sa vii cu niste date care sa-mi arate sau demonstreze cumva ca ai scris cod care face ceea ce trebuie.
Pe termen lung (6 luni+), testele unitare devin OBLIGATORII pentru orice proiect software. TDD te poate incetini doar daca toata echipa respectiva este junioare la scris teste sau la TDD.
Pe termen lung insa, TDD cuplat cu refactoring continuu iti da posibilitatea sa nu incetinesti in a livra functionalitati noi.
Sa ridice mana cine nu s-a gasit cel putin o data in situatia urmatoare:
- Proiect nou, inceput de la zero. Orice feature cerut de manageri (sau product owner) primeste estimari de 1-2-3 saptamani. Programatorii fac treaba foarte buna la inceputul proiectului si livreaza peste asteptari sau conform asteptarilor.
- Dupa 1-2 ani, vine managerul si cere un feature nou aparent minor ca si valoare de business. Programatorii se iau cu mainile de cap: -“Dar asta schimba totul, trebuie sa refactorizam tot proiectul/modulul. Dureaza cel putin 1-2-3+ luni”.
Are cineva vreo explicatie de ce implementarea functionalitatilor noi sau modificarea celor existente tinde sa incetineasca cu cat proiectul are o durata mai mare de viata? Nu la modul general, dar cred ca in 80% din proiectele software mari se intampla acest lucru.
Si de ce dupa 4-5-8 ani multe proiecte software trebuie rescrise de la zero?
Subiectul este complex si depinde de proiect, insa pot mentiona cu siguranta cateva cauze, din experienta personala:
- nu se documenteaza niciodata nimic
- multe detalii raman in discutii avute pe email/slack/etc
Intervine și rutina, oamenii își pierd motivația
Pai si daca defectele respective ajung in productie ce faci? In functie de proiect poti fie sa afectezi incasarile fie sa blochezi departamente intregi. Nu prea vad cum acest lucru ar avea legatura cu bugetul ori numarul de programatori.
Impactul, fie ca esti Amazon, fie ca esti un mic magazin este financiar raportat la cifra de afaceri si este acelasi. La fel si in situatia in care este un proiect intern.
E curios ca ai pomenit de acel 80%, pentru ca se aplica regula 80:20: 80% din functionalitate necesita 20% din timp, si restul de 20% necesita 80% din timp. E ceva calitativ, bineinteles ca poate fi 90:10. Sau 99:1. Etc.
Explicatia nu e ca de-aia ca n-ai TDD, e un pic mai complicat de atat. De exemplu, una e sa scrii cod de la zero, alta e sa ai un milion de linii de cod pe care sa trebuiasca sa-l extinzi. Mai e o chestie cu prioritizarea, ca de obicei se lucreaza in proiecte la inceput la chestiile care se pot scoate urgent, apoi se trece la tot felul de detalii… si diavolul e in detalii.
Eu am inceput programarea la un start up, unde eram 4 juniori si un senior. Dezvoltam produsul propriu. L-am intrebat pe sef la un moment dat cand sau de ce nu incepem sa facem si testare pentru aplicatia respectiva. Nu aveam timp in momentul respectiv si nici nu ajutau prea mult. Trebuia dezvoltat un mvp cat mai repede pentru ca aveam clienti care il asteptau, iar firma n-ar fi supravietuit probabil fara sa aibe un produs lansat cat mai repede. Apoi, cand am inceput sa integram clienti in aplicatie, fiecare a venit cu cerinte personalizate si a trebuit sa facem dezvoltari noi sau modificari astfel incat sa acopere nevoile fiecaruia. Am fost acolo timp de 2 ani, de la inceput. Pana atunci, n-am avut cum sa facem teste, odata cu dezvoltarea aplicatiei. Sau daca am fi pierdut timp pentru asta, in loc de ~ 60 clienti cat stiu ca au acum, ar fi avut probabil 20, sau 30, sau n-ar mai fi existat firma.
Sunt cazuri si cazuri. 
Eu unul am evitat testarea pe cât am putut.
Mi-a fost cam jenă de treaba asta până recent.
Am crezut că numai eu nu folosesc/știu unit testing.
Însă am avut ocazia să colaborez cu un consultant/arhitect de aplicații care a recomandat unit testing dacă platforma dezvoltată nu este modulară.
Și eu am realizat că dacă modulele sunt bine izolate șansa de a avea bug-uri critice este redusă.
Mi se pare că cu cât este mai OO codul, cu atât mai stabil este.
Cu alte cuvinte, vrei sa spui ca nu exista disciplina, nu? Desi suntem programatori, adica oameni tehnici si ar trebui sa lucram si sa comunicam intr-un mod foarte bine organizat si structurat, etc., de multe ori lucram cam dupa ureche sau pe ideea “las-o bre, ca merge-asa!”.
Apoi vine intrebarea: cine ar trebui sa documenteze si cum? Si cand?
Din intelegerea mea limitata, tocmai asta incearca sau propune TDD, impreuna cu “good architecture & design”, clean code si refactoring continuu sa “rezolve”: lipsa formalizarii sau disciplinei/disciplinelor din proiectele software.
Din cauza ca dezvoltarea software nu este absolut deloc reglementata (ca profesia de medic, de exemplu, sau contabil), este o mare “jungla”. Eu cred ca chestia asta are si parti bune, dar si parti mai putin bune.
La medici cum de nu intervine rutina? Medicii cum de nu isi pierd motivatia dupa ce fac 2000 de operatii de acelasi fel?
Mai e o chestie care mi se pare interesanta: cati dintre noi, ca programatori (si cat de des), ne punem intrebarea: cum afecteaza codul scris de noi VIATA altor persoane? Ce impact avem asupra celorlalti?
In lumea de azi nu cred ca trece o ora fara sa interactionam cu un calculator care ruleaza cod scris de niste programatori.
Insa din cauza abstractizarilor cu care lucram, nu prea ne dam seama de impactul real pe care il produce codul scris de noi asupra altor oameni.
Cred ca din cauza asta medicii nu prea isi permit sa isi piarda motivatia. Ei stiu ca o greseala minora sau o clipa de neatentie sau “ia sa nu ma mai spal pe maini 10 minute inainte de orice operatie” poate avea un impact major asupra vietii unui om.
Cum ar fi daca noi ca programatori ne-am gandi la TDD ca la “spalatul pe maini dinainte de operatie”? 
Am cochetat putin cu TDD in cadrul unui code retreat. Am observat ca este putin mai greu sa scrii un test pt ceva ce inca nu ai implemetat. Dar banuiesc ca te obisnuiesti in timp.
Pe proiectul actual sunt destul de multe teste. Pt mine, sunt o garatntie ca ceea ce scriu pe acolo este corect.
Chiar acum rescriu logica pt preferintele utilizatorilor in aplicatie si a fost nevoie insa sa modific putin si testele. Ca nu se mai pupau cu modificarile.
Am lucrat si pe proiecte cu 0 teste, mai ales pe partea de business logic. Aplicatie care calcula cotatii pt clienti.
Da, este mai greu sa scrii intai testele pentru ca te obliga sa te gandesti la o multime de scenarii care se pot intampla. Dar tocmai in asta consta beneficiile TDD: iti ofera mai mult timp sa gandesti, ceea ce pentru multi programatori poate parea un lux 
.
O alta frumusete a TDD este ca in momentul in care ai epuizat testele pe care le poti scrie pentru o anumita problema, ghici ce? Ai rezolvat problema!
Nu stiu daca toti isi dau seama, dar sa scrii cod e greu. Trebuie sa te gandesti la mii de lucruri in acelasi timp, iar creierul uman are un singur thread . Cred ca tocmai din acest motiv ne trebuie mai multa disciplina, pentru ca nu putem tine in memorie tot codul pe care il scriem, nici macar codul scris intr-o zi.
Apoi, sa scrii cod bun din prima este o himera. Este imposibil si nimeni nu face asta. Disciplina sau lipsa ei se vede abia din momentul in care codul a fost scris si functioneaza. Ce facem mai departe? Il lasam asa si trecem la urmatoarea problema sau il curatam si il facem lizibil si pentru ceilalti colegi? Sau pentru noi din viitor?
Simplu, medicul face operația și termină „proiectul” după ce pacientul se externează. Nu sunt foarte mulți pacienți care „dom’ doctor, știți transplantul ăla de ficat? Eh, m-am gândit eu mai bine, am nevoie să-i punem niște beculețe și motorașe?” 
La toate proiectele unde mi-am pierdut motivația, am făcut-o - în mare parte - din cauza oamenilor implicați în proiect, mai puțin din cauza codului sau a features cerute.
Aici voiam sa ajung si eu: cand intervine rutina si programatorii isi pierd motivatia, e semn ca in echipa respectiva sunt (si) alte probleme, nu neaparat de natura tehnica.
Cred ca programarea este una dintre cele mai creative meserii din lume care te poate tine motivat o viata intreaga, asa ca eu cand vad colegi programatori care se plang ca a intervenit rutina sau nu mai sunt motivati, incerc sa vad dincolo de chestiile tehnice.
Nu cred ca vrea nimeni sa lucreze dupa ureche, dar de multe ori nu avem de ales.
In mod normal business analyst-ul ar trebui sa se ocupe de documentatie.
Am și eu o curiozitate, cineva a lucrat vreodată pe un proiect unde se făcea pe bune tdd? Adică testele întâi? Eu nu am întâlnit pana acum, de asta întreb.