nimeni din comunitatea rails il iau in seama pe dhh. el este software writer, eu sunt software engineer, precum restul oamenilor. Nu’s ruby dev, php dev, java dev.
Din experienta, TDD este foarte util. Imagineaza-ti ca scrii un feature, apoi peste 4 luni, trebuie sa schimbi ceva in cod, care poate atinge sau nu, parti din applicatie. Cum verifici?.
dupa patru luni, codul se schimba, se solidifica, clar nu stii exact ce ar trebui sa faca. Asa apar bugurile.
La munca, avem un REST api, are 100% coverage. Sunt mandru de asta
Pai asta e the basic tenet of TDD, sa te gandesti inainte la cazuri de tot felul si sa scrii teste pt ele. I know that. Dar cum ziceam, nu poti acoperi tot (cel putin nu cand sunt chestii complexe). Daca nu stii ca 5/2 = 2 poti sa fii tu cel mai mare as in TDD
Si nu merge sa zici ca no, daca-s omisiuni pai lasa sa fie. Utilizatorului ii pasa doar sa-i mearga aplicatia – deci o data ce a fost gasit un bug, pai la naiba, trebuie reparat. La asta se reduce tot. Si sunt destui bugsi pe lumea asta cat sa nu fie mereu evident ochiometric ce se intampla, ca sa n-ai nevoie de debugger.
Dar nu inteleg de ce zici ca “nu vei avea niciodata un test care sa fail-uie pe codul gata scris”. Pai motivul 1, 2 si 3 pentru care eu sustin utilitatea testelor este faptul ca reduc posibilitatea de regression (unde regression = bug-uri introduse reparand altceva, adica fix teste care treceau acum nu mai trec). Sau n-am inteles eu bine ce-ai zis?
Cred că cea mai grea parte din TDD are loc înainte de red green refactor și este dezbinarea scenariilor complexe din lumea reală în teste simple. Dar o dată ce ai reușit sa faci acest lucru, pe lângă faptul că nu vei avea chestii complexe în codul tău(SOLID), vei avea și 100% încredere în testele tale care îți oferă mult mai mult decât diminuarea regresiunilor.
@Kay Ce vroiam sa zic ese ca daca faci TDD, incepi cu testul, evident. Deci orice cod de productie ai avea, el a fost scris sa faca testul sa treaca si nimic mai mult. Adica in momentul cand ai ajuns sa faci acea impartire, deja ai testat suficient incat sa nu ajungi in cazul tau. … Poate un algoritm putin mai complex ar putea exemplifica mai bine. Ma gandesc la ceva concret pentru un raspuns ulterior.
Iar daca descoperi un bug in productie / testare vizuala, dupa aia faci un test automat sa reproduca bug-ul, si numai dupa aceea scrii codul care sa il rezolve.
Recunosc, nu ar fi trebuit sa folosesc cuvantul “niciodata”. In schimb folosesc “exista sanse foarte mici”.
Un lucru care ma convinge pe mine in ceea ce priveste TDD-ul este faptul ca mi se pare ca se potriveste cu OOP-ul. OOP inseamna programare “by contract” , iar TDD-ul te ajuta sa scrii “contract”-ul inainte sa il implementezi.
@csmdev Faptul ca scrii teste (specs) inainte de a scrie codul de implementare nu are nicio legatura cu Waterfall sau metodologiile evolutionare (agile family, etc). E un simplu mod de a ataca implementarea. Unii fac schite pe hartie altii scriu teste
Out off topic: Waterfall a aparut in anii '80 si a murit mai mult din motivul ca bussiness-ul nu putea fi atat de “batut in cuie” precum presupunea metologia si nu din motive de proasta implementare a codului. Poate ai fi surprins ca prin anii 70 la IBM se lucra in “evolutionary phases” (care aveau cateva saptamani).
Unde e buton-ul de dislike la aceasta afirmatie, TDD nu e mort si nu va fi, e best practice, daca nu scrii teste te intrebi de ce nu ai tratat toate flow-urile si codul tau e plin de bug-uri , nu trebuie sa o iei ca ceva personal(ego less programming).
Cred că - cel puţin aşa am înţeles eu - în post-urile de mai sus, nu era ceva anume împotriva testelor, şi poate nici chiar împotriva creării testelor înainte de codului aferent, ci împotriva unor practici TDD (posibil greşit înţelese sau duse la extrem), precum axarea pe teste prea low-level şi faptul că aceste teste devin (un) factor decisiv, care determină design-ul codului.
Nişte (contra)exemple, pe care le-am văzut real-life:
crearea de teste doar la nivel de metode, pentru a avea test coverage de 100%
(ceea ce nu garantează neapărat funcţionarea corectă a unei componente)
sacrificarea încapsulării (i.e. a design-ului), prin crearea de metode care primesc ca parametru un membru din aceeaşi clasă, pentru ca metoda să fie mai “potrivită pentru testare” (!=OOP)
crearea, în aceeaşi clasă, a unor miriade de funcţii cu maxim 5-6 linii de cod (again, design), tot în onoarea code coverage-ului de 100%
Clar, motivaţia această este perfect pertinentă (ziceam doar de cazul în care testarea este motivul).
Oricum 10-15 linii e o valoare mai de bun simţ decâţ 5-6
, nu trebuie sa o iei ca ceva personal(ego less programming).
