Cine a a incercat sa adopte TDD? As fi intereset de cateva experiente personale:
- unde i-a fost cel mai greu si cum a trecut peste
- unde a lasat-o balta
- etc
Eu nu am reusit 
1 Like
e greu sa pui un client sa plateasca teste.
“si astia 20%?”
“aaah, alea-s testele”
cand lucrezi la proiecte inhouse si e buget pt asa ceva, e alta treaba.
1 Like
Văd beneficiile testării. TDD pare ceva extrem de natural din punct de vedere conceptual. Daaar…
Am tot încercat eu și în JS și în PHP (de fapt WordPress). Am „copt” la proiectul ăsta în speranța că-mi voi schimba obiceiurile de programare (dar s-a dovedit a fi o porcărie cruntă, în primele vreo zece episoade arată absolut orice numai cum să faci TDD nu; poate se schimba în restul episoadelor, nu știu).
Mi s-a recomandat recent cartea Testable Javascript, dar încă nu am cumpărat-o (pentru că nu cred ca voi avea timp prea curând și pentru că sunt puțin reticient după ce m-am ars cu proiectul menționat mai sus).
Foarte multe s-a clarificat după ce am vizionat tutorialul ăsta. Este singurul tutorial ce m-a prins de la început până la sfârșit. Dar, chiar și așa, sunt multe lucruri care îmi scapă.
Probleme Comune
Evident, problema cea mai mare este modul în care sunt prezentate tutorialele: uite, facem un calculator și testăm. Yay, gata tutorialul. Iar asta în cel mai bun caz! De obicei un tutorial TDD înseamnă, de fapt, introducere în xUnit. Foarte rar se precizează ce trebuie testat sau cum să scrii codul pentru a putea fi testat. Sau măcar că trebuie să scrii codul într-un anume fel! (hint, princiiple SOLID ajută foarte mult la scris cod ușor testabil)
În JavaScript / PHP
O mare parte din codul scris de mine în JS este, de fapt, jQuery. De testat, ar însemna să testez metodele din jQuery, ceea ce este cel puțin naiv. La fel și în cazul WordPress. Ce aș putea testa? Dacă metodele WP fac ceea ce fac deja? 
La WP este, de fapt, mai dificil. Fiind un sistem ce nu a avut teste din start, s-a scris un framework ce extinde PHPUnit în așa fel încât clasele și funcțiile WP să suporte teste. Problema este alta: orice test, oricât de simplu ar fi, durează câteva secunde să ruleze. Toată suita WP durează vreo 15 minute. Demoralizant…
În JS mi se pare foarte peste mână să testez interacțiuni ce conțin event-uri
Învăț
Am încercat să fac un fel de Dojo: mici bucăți de cod testate pe toate părțile: un calculator (!!), un generator de numere prime, an bisect, știi, toate chestiile de bază (ideea este să te concentrezi pe scris teste la început, nu pe scris cod). Am pus pauză în urmă cu câteva luni deoarece am avut prea mult de lucru și prea puțin timp.
@AdrianBasalic: Chiar dacă nu o practic, testarea ar trebui să fie ceva inclus în preț, nu ceva opțional. Croitorului nu îi spui „dacă nu măsori o să mă coste mai puțin, deci nu mai folosi metrul!”. Programarea este o meserie ca oricare alta ce are costurile ei. Cereți bani clientului că testați manual dacă aplicația funcționează?
4 Likes
Nu vad o problema in a explica unui client. Cu siguranta ca sunt multe activitati pe care le fac in banii pe care ii cer si nu i le dau atat de granulat.
Cel mult ii pot si explica necesitatea. Ca sa fac o paralela, ar fi ca o masina care are un sistem de verificare si oricand iti modifica cineva ceva la ea, iti poti da seama daca e o problema.
2 Likes
Ionuț, tdd pe wp? Rili?
1 Like
@alescx: rili. Nu la o temă, desigur, că acolo, de cele mai multe ori, chiar nu ai ce testa. Dar la plugin-uri… oho!
WPML - plugin-ul pe care l-am tot folosit de vreo doi ani pentru multilanguage - a introdus la un moment dat un bug care desincroniza toate posturile. Sigur, nu e o problemă foarte mare la un site de prezentare, dar la momentul respectiv aveam câteva mii de post-uri. Dacă ar fi existat teste, ce crezi, s-ar fi întâmplat asta? 
Testele scrise după ce s-a scris codul sunt un pic peste mână. Revenind la exemplul meu de mai sus, imaginează-ți un croitor care întâi taie și abia apoi măsoară.
1 Like
Din fericire, clientul proiectului de la firma vrea unit testing, iar noi am fi vrut sa mergem in tdd. Dar nu iese cum ne-am propus, motivele fiind impartite intre experienta, dezinteres, dezorganizare si o documentatie a carei descifrare ocupa mai mult timp decat codul uneori. Scriem teste, dar asa, dupa cod, cand ne amintim.
1 Like
Teoretic ar trebui sa faci testele inainte
Pai, a face unit testing inseamna a scrie testele indiferent de moment. Cand vorbesti de tdd, atunci apar niste metode/reguli care spun sa incepi cu testele.
1 Like
@AdrianBasalic @Catalin_Banu - cu TDD e drept ca il costa la inceput, dar economiseste pe parcurs.
Cand se va implementa o functionalitate extra ulterior e mult mai usor de testat totul cand ai facut de la inceput toate testele frumos decat sa o faci manual.
E drept, costa cu X% mai mult proiectul, insa la viitoarele “interventii” pe cod, treaba se va face mult mai rapid si clientul va iesi in castig (less time doing, less money paid).
E e drept ca pentru un proiect mic care nu are sanse de extindere un client nu cred ca ar intelege de ce trebuie sa mergi pe TDD.
2 Likes
Dacă îl cunoaște cineva pa Patkos Csaba și l-ar invita pe forum, ar fi interesant să răspundă la câteva întrebări.
Ar fi fost interesant să facă respectivele cursuri (și) în română 
Câteva idei despre cum să vinzi teste la client găsești în cartea asta. Acolo găsești explicații și despre cum să selectezi părțile care trebuie testate din proiect (multe componente poate sunt foarte puțin utile, și pot fi lăsate fără testare în primă fază).
Cred că toți care se apucă de TDD ar trebui să citească și principiile SOLID, ajută foarte mult.
Tot la capitolul ăsta cred că ar trebui menționat și Behavior-Driven Development, care din punctul meu de vedere te ajută să scrii teste mai relevante pentru client/business.
5 Likes
Am dat un tweet
BDD - ul dureaza mai mult. Unit testurile ar trebui sa dureze maxim 1-5 minute.
1 Like
Ai fost mai frumos in exprimare. Sunt prea obosit . E o idee buna de head hunting pentru programatori romani sa vina pe acest forum. Apropo de Cum sa promovezi un forum in Romania? . Deja il asteptam pe zoso.
Nu cred ca clientul are un cuvant de spus in crearea testelor. TDD-ul si BDD-ul e parte din treaba noastra de programatori.
NIci nu cred ca trebuie informat, o aplicatie instabila ma deranjeaza oricum mai mult pe mine decat pe el, ca ma trezeste noaptea sa-i repar bug-uri in urma “mai vreau x lucru” de ieri.
2 Likes
Poate am înțeles eu greșit, dar TDD nu presupune să rulezi testele rapid și constant?
Eu tot ce am făcut TDD am făcut-o cu un watcher în fundal, dura mai puțin de o secundă (cel mai mult am avut în jur de 50-60 teste). Consola îmi bagă un bip în căști dacă testele pică; nici nu trebuie să schimb fereastra
Păi cum ar fi să scrii o metodă și să aștepți trei minute să o testezi? 
Cine ar mai rula testele?
1 Like
Sunt situatii in care testele dureaza si 20 minute (din ce am am auzit la altii).
In varianta ta de watcher nu ruleaza doar testele modificate? In PhpStorm imi rulez doar pe cel curent (in care lucrez). Am si buton pentru toate, dar de rulat toate rulez inainte de deploy.
1 Like
Nu cred ca durata e o problema.
Eu merg mai usor pe modul scriu testele, implementez feature-ul si doar dupa ce termin rulez testele. In timpul in care rulez testele(cateva minute) pot sa postez aici de exemplu.
Iar atunci cand vine vorba de versionare public direct commit-ul iar in caz de ceva rau TRAVIS este cu ochii pe commit-urile mele.