TDD is dead.
7 Likes
Asta in conditiile in care consideri ca TDD e mai lent decat dezvoltarea originala.
Desigur, sunt de acord ca exista cazuri in care vrei sa renunti la tot, faci un “walking scheleton”, il scoti pe piata si vezi feedback.
Dar dupa aceea, produsul real, va trebui sa il faci pe bune.
Ah, si TDD merge pe waterfall? E prima oara cand aud asta. Poti sa elaborezi?
PS: poate intram intr-un topic diferit si un alt thread ar fi mai potrivit. Acum, sa revenim la challeng-ul propus.
1 Like
Nu știu cum ai făcut corelația asta, dar e eronată. Cred (și s-ar putea să mă înșel) că ai o impresie greșită despre ceea ce înseamnă TDD. Iar viteza nu este totul. Degeaba scoți primul un produs dacă e buggy. Cine o să-l folosească? Cine o să revină la produsul tău după ce a fost dezamăgit în primă fază?
1 Like
E amuzanta asta. Daca pentru tine development inseamna sa scrii o linie in cateva secunde si dapa aia sa testezi manual inca 5 minute iti pot recomanda o cariera la McDonalds.
1 Like
Nu la TDD, scrii testele în paralel cu implementarea.
Nu e vorba să-l faci perfect dar să-l faci funcțional, și să încerci să acoperi unele cazuri critice.
2 Likes
Nu credeam că oamenii de aici iau tot ce e scris mot-a-mot… În fine.
Indiferent dacă scrii pentru un Minimum Viable Product sau pentru orice altceva, codul tău trebuie testat. Dacă tu scrii o clasă/funcție, dar înainte să începi să o implementezi, scrii testele pentru cazurile particulare, și pe baza acestora realizezi și design-ul, părerea mea e că ești mult mai câștigat. Nu vorbim de cât de mult ajută în cazul refactoring-ului.
2 Likes
Si daca se schimba ceva in cod te apuci de retestat tot in ui? Sau esti genu care da copy/paste la cod si modifica doar daca-i nevoie/
1 Like
Interesant cum a deviat acest topic. Dar pe principiul “Open space”: “Whatever we talk about is the right topic to talk about”, hai ca ma mai bag un pic.
Vad cu tristete ca discutia duce spre acuze nefondate si destul de dure cateodata. Hai ca suntem oameni civilazati si nu are rost sa ne acuzam de vari chestii.
Ce inseamna agile? In nici un caz nu are nici o legatura cu ordinea in care implementezi. Agile inseamna:
- Individuals and interactions - adica colaborare in echipa, pair programming, continuous learning, etc.
- Working software - pentru asta e nevoie de testing, TDD, continuous integration/build/deployment, clean architecture, etc.
- Customer collaboration - adica ascultam feedback. De acord, as implica release cycle mai scurt.
- Responding to change - adica nu ne ia 3 luni sa fixuim un bug fara sa introducem altele 10.
Acum nici unul nu te obliga sa faci TDD. Doar ca in mare parte a cazurilor te va ajuta. Cum te va ajuta?
- Testele te fac sa intelegi ce e de facut
- Codul va reflecta tot timpul “specificatiile” din teste
- Da, daca se schimba o cerinta, schimbi testul sa reflecte noua cerinta, dupa care scrii codul. Este singura metoda 100% de a demonstra ca implementarea face chiar ce s-a cerut a fi facut
- Nu mai e nevoie sa scrii documentatie de cod. Oricum acesta devine “legacy” si “outdated” in secunda in care se da commit. Singura documentatie adevarat pentru cod sunt testele. Iar singura metoda de a “documenta”, adica testa tot codul de productie, este sa scrii testele inainte.
- TDD nu te incetineste, TDD te face de 2x mai rapid
- Daca ai un bug, singura metoda de a afla exact de ce se intampla acel bug este sa scrii un test care reproduce bug-ul. Din acel moment, ai o dovada a bug-ului si o demonstratie a ce conditii il reproduc. Scrierea codului este pasul doi. Bonus, ai si test de regresie automat.
Ah, si cand in agile se zice ca scoti produs repede sa ai feedback, asta se refera la o singura chestie si numai una: Scoti un produs cu un set foarte redus de feature-uri, implementate si testate, cu un numar minim de buguri. Scopul este sa iti dai seama daca ceea ce faci este ce vrea piata. Scopul nu este sa faci 10 feature-uri pe jumatate sau cu bug-uri si sa-l faci beta si sa le dai publicului. Daca faci asta, nu esti nici agile nici waterfall. Esti doar pe calea cea mai buna spre esec.
Vrei agile si feedback? Fa release frecvent, testeaza tot … TOT! … fii sigur ca ce dai nu va dezamagi clientul. Nu da 10 functionalitati proaste niciodata. Da 1 sau 2, ia feedback, si dupa aceea decide care va fi functionalitatea 3 sau 4. Asta este agile. Dar pentru asta trebuie sa demonstrezi ca vei stii sa faci 3 si 4, si singura metoda este dai 1 si 2 de o calitate atat de buna incat sa fie atractive.
Iar cand vine vorba de acuze de “pun pariu ca tu nu faci agile”, sau “TDD e waterfall”, eu va vorbesc din experienta. Ceea ce facem noi la Syneto, cum lucram noi la Syneto, ce am invatat si ce ii invatam pe ceilalti, vor deveni un “Agile Experience Report”. Un document publicat pe site la agile alliance, alaturi de un grup select de firme, si nici una romaneasca din cate stiu eu. Mai mult, am fost invitat sa merg in State sa prezint toate aceste lucruri la conferinte internationale ale lui Agile Alliance.
Poate va intrebati de ce am dat raspunsul de mai sus? Nu, nu pentru a ma lauda. Ci pentru ca atunci cand se fac acuze, lucrurile devin personale. Si da, unele chestii trebuie sa le iau personal.
Eu cred ca existe metode de a scrie software intr-un mod mai bun.
Eu cred ca Agile reprezinta mult mai mult decat tehnici.
Eu cred ca cel mai important lucru este sa incerci, sa faci (minim 6 luni) o tehnica, si sa decizi in cunostinta de cauza.
Eu cred in comunitatea software, in oameni rationali, in profesionisti adevarati … nu stiu daca pentru “CraftsMen” este un cuvant in romana.
Eu cred ca numai confruntandu-te cu altii, motivand ideile si deciziile tale le poti solidifca pentru tine si pentru cei din jurul tau.
Iar pentru toate astea este nevoie de o atitudine civilizata, si de raspunsuri rationale, nu emotionale.
Acum, oricine, din experienta, poate sa dea exemple punctuale pro sau contra unor subiecte, va afla ca cele mai bune discutii se vor insca din acestea.
5 Likes
Gresesti amarnic aici. N-o sa comentez despre fanatismul tau legat de Agile (care pentru unii poate fi doar un overhead imens), dar sper ca stii ca in developmentul modern se fac si teste functionale care nu tin doar de backend ci de workflow-uri. Daca te-ai fi documentat putin mai mult ai fi stiut asta.
Teste functionale exista pentru majoritatea limbajelor/framework-urilor, iar daca nu exista tool specializat pe teste functionale poti face oricand teste cu Selenium.
Poate te-ar ajuta mai putin bashing si mai mult RTFM!
Doua chestii:
- Exista si tools pt automated front-end testing.
- “Live testing”/“lasa ca vezi problemele manifestandu-se in UI” sunt strategii care merg numai in cazuri de complexitate redusa. Cand ai un proiect din-ala cu 500 de path-uri posibile pe care le poate urma utilizatorul, plus vreo suta de edge cases (daca utilizatorul apasa pe pixelul verde din colt, stand intr-un picior, cand afara e luna plina)… apai la alea fara automated testing esti mort. Gandeste-te numai ca timp, cat ti-ar lua de fiecare data sa incerci asa de mana toate combinatiile posibile de actiuni, si nu mai zic cat de mari sunt sansele sa mai uiti cate unul, doua, noua edge case-uri la fiecare test pass.
1 Like
Well…
Am inceput TDD (ma rog, automated testing in general, sa nu ne incurcam in keywords) de ceva ani buni. Dar cum ziceam, e usor sa-ti dai seama ca ceva nu merge; sa-ti dai seama de ce nu merge e cu totul alta mancare de peste.
Un exemplu de programator incepator (da, mi s-a intamplat mie, ce e drept acum foarte mult timp): in framework-ul pe care il folosesc eu daca imparti doua valori intregi rezultatul va fi mereu un intreg (gen 5/2 = 2). No, sa zicem ca am o metoda de genul
int a = 5
int b = 2
return (a/b + 10) * 2
(cum ziceam, ceva super basic)
No, un test imi zice ca in loc de 25, cum as vrea eu, metoda mea returneaza 24. Si mai departe? (assume ca sunt suficient de incepator ca pe moment sa nu-mi treaca prin minte chestia cu intregii si rezultatul intreg)
Bine, si mai am – cazuri minore de genul o bucla infinita pentru ca ti se reseteaza pe undeva pe la mijloc counterul (somehow, nu-mi vine in minte un caz plauzibil, dar am patit si asa ceva), sau favoritul meu de pe vremea cand lucram in WinForms (don’t judge, it was a decade ago) cand aveam o linie de cod asa:
chestie.visible = true;
Evident chestia nu voia sa apara si pace, si ce era cel mai frumos e ca daca te uitai cand rula codul, fix pe linia de dupa aia de-am zis-o mai sus valoarea lui chestie.visible era false. Desi numai ce-o setasei si teoretic nu se intamplase nimic intre! Situatie pe care iti doresc o gramada de succes s-o rezolvi asa, ochiometric si cu teste 
Deci nu, pentru mine personal nimic, dar nimic nu e ca debuggerul. Restul chestiilor te ajuta eventual sa ghicesti cam ce se poate intampla cam pe unde. Dar cu debuggerul n-ai nevoie sa ghicesti nimic, te poti uita direct si sa vezi. It saves a lot of time. Cum am zis inainte, daca e nevoie ma pot descurca si fara, deci nu e ca si cum mi-s legata hand and foot de debugger – at the end of the day e doar un tool; dar unul super util
1 Like
Nu ma gandesc doar la web 
Ca idee, am lucrat vreo 5 ani pe desktop (sau mai mult) si vreo 4-5 ani backend pt web. Am facut si fac si ceva front end din cand in cand, cand e nevoie, dar paradigma mea mentala clar nu are la baza web apps.
Sa-ti mai zic ceva. Ce-am facut eu mult (si ce m-a convins ca viata fara automated testing nu merita traita) (ca inainte de asta imi era lene sa scriu teste 
) a fost sa scriu motoare de calcul financiar (da, imi dau seama cum suna, nu gasesc acum termen mai bun). Basically un mare teanc de cod, la un capat al caruia bagi niste numere, calculeaza o gramada, si iti scoate alte numere pe la capatul celalalt. Ori, o chestie complexa are o gramada de mici rotite prin ea, nu ai cum sa fii sigur ca atunci cand adaugi/scoti ceva n-ai mai stricat si altceva pe langa (modularizarea e una, dar cand ai complex math stuff nu toate chestiile sunt rezolvabile prin arhitectura, tre’ sa fii sigur si ca ti-s formulele corecte si acopera tot ce trebuie).
1 Like
de ce spui ca TDD este mort?
Eh. Tu ai zis ceva de live testing c-ar fi preferabil, si tot tu ai zis la un moment dat ceva de genul ca meh, daca sunt bugs ii vedem in UI. Ce incerc eu sa zic e ca automated testing e important. Acum, ca-i zici TDD sau altfel, nu mi se pare nici important nici relevant; keywords are overrated.
Also, eu credeam c-avem o conversatie si atat. Inamic (chiar si imaginar) e un pic mult spus – macar pt. ca suna a ceva teribil de consumator de energie si nervi
1 Like
@csmdev Fiecare dintre noi avem convingerile noastre.
Nu sunt un manager. Sunt un developer. Vrei numere? Nimic mai simplu:
2009
- Release cycle 9 luni planned, aprox 10 reali
- Buguri > 50 / release gasite in productie
- 1-2 feater-uri per release
- 2-3 luni doar de integrare componente
2014
- Release cycle - 3 luni, ca asa vor clientii
- Tot 1-2 big features per release
- In medie 3 bug-uri / prelease, adica undeva la 1 / month
- Integrare aproape zero … mai facem niste “smoke testing” inainte de relase cateva zile si atat
Si tot pentru @csmdev, poti sa ne explici te rog ce intelegi tu prin TDD? Ca pana acum ai zis chestii vagi, cum aca nu iti place, nu este de acord, etc. Zi-mi un exemplu care ai incercat, masurat si nu ti-a mers. Si zi ne si de ce nu ti-a mers. Cel mai usor este sa dai vine pe cineva sau ceva.
Diploma agile? Ce diploma? Cand am vorbit eu despre diplome? Daca crezi ca tot ce zic eu este doar “manager talk”, de ce sunt eu invitat sa vorbesc / scriu pentru Agile Alliance si nu tu?
Ah, si din experienta mea, nici una din punctele raspunsului acceptat la linkul tau nu sunt adevarate. Iar toate definitiile sunt cu “poate” acolo. Asa ca, tot ce zice acel raspuns este ca cineva crede ca acele lucruri “s-ar putea sa fie” adevarate partial sau total.
@Kay
Pentru codul tau, in mod natural, cu TDD, ai avea mult mai multe teste. Testele ar fi denumite pe cazuri exceptionale si comune. Iar testul care ti-ar confirma functionalitate ar fi ceva de genul “whenTheTwonNumbersAreNotDivisibleTheResultWillBeFloored()” care va testa exact cazul tau.
2 Likes
Ahem. Asta merge in cazul in care stii ca whenTheTwonNumbersAreNotDivisibleTheResultWillBeFloored e o posibilitate. Dar in ce ziceam eu ideea era ca dintr-un motiv sau altul nu ai luat in calcul posibilitatea respectiva (poate ai testat numai cu numere divizibile intre ele, poate nu stii ca limbajul iti face de-astea, poate fiind cu mintea in alta parte ti-a scapat). Ideea era cum afli ca rezultatul e floored in cazul ala, nu cum confirmi dupa aia ca da bai, e floored
1 Like
Da. Inteleg. Asa inveti. OK, folosesti debugger. Dar inveti din greseala si data viitoare te gandesti mai bine. Daca faci TDD si te gandesti activ la cazuri exceptionale, mare parte a erorilor le poti elimina.
Ah, ca vor fi lucruri despre care nu ai stiut? Asta este doar experienta in opinia mea.
1 Like
Asta e clar. Testele exista si pentru (ca sa nu zic mai ales pentru) edge cases de-astea dubioase. Dar stii cum e, daca te-ai putea gandi de la inceput la tot ce poate merge gresit pai n-ar mai fi bug-uri. Ever
Sigur ca pe masura ce capeti experienta esti din ce in ce mai obisnuit sa detectezi breaking points de-astea. Dar eu cred ca-s complementare debugging-ul si testing-ul – intai faci greseala (pana si aia experimentati fac greseli, pana si eu!), dupa aia debug-ai ca s-o gasesti, si dupa aia scrii un test ca sa te asiguri ca nu se mai intampla.
Edit: formulare aiurea
1 Like
Ce am gasit eu interesant este ca atunci cand te gandesti activ la edge case-uri, iese codul mai bun. Iar ce metoda mai buna este sa te gandesti la acele cazuri decat sa scrii teste pentru ele in prealabil si implementare dupa? Parca te forteaza sa parasesti happy-path-ul.
Si daca faci asa, nu este posibil sa ajung in cazul tau. Adica nu vei avea niciodata un test care sa fail-uie pe codul gata scris. Nu va trebui niciodata sa iti pui problema asa cu ti-ai pus-o tu.
Ah, ca vor fi omisiuni, desigur. Si in mare parte a cazurilor sunt omisiuni datorate lipsei de cunoastere a domeniului problemei. Dar asta e o alta poveste.
2 Likes