The Transformation Priority Premise by Uncle Bob - TDD

Conceptul de prioritate a pasilor cand faci TDD este unul introdus de Robert C. Martin (Uncle Bob) si numit The Transformation Priority Premis. Il consider unul dintre cele mai importante premize legate de TDD. Chiar daca este greu de retinut si respectat, cu siguranta este ceva ce merita citit si tinut minte.

Aveti aici articolul scris original, precum si un video de la o conferinta.

Have fun.

5 Likes

Am dat de articolul respectiv acum ceva timp și am fost impresionat. Atunci am realizat că că există și modalitatea greșită de a face TDD. Dacă nu respecți prioritățile de acolo poți ajunge la rezultate care lasă de dorit când vine vorba de mentenanță (cod aiurea, teste fără sens și greu de modificat pe viitor).

Exista undeva in Romania vreun loc unde se poate invata TDD si/sau DDD?
Eu am inceput sa studiez de unul singur, dar desi am inceput sa am idee si sa inteleg niste concepte, parca tot imi e peste mana sa implementez TDD. La munca, oricum, nu as putea face asta…

1 Like

De ce nu ai putea face asta la muncă?

Daca vreti si va adunati vreo 10-15 persoane, va tin eu un curs, contra
cost. Daca sunteti interesati nu ezitati sa ma contactati.

Eu vreau. Am urmarit o parte din cursul de design patterns de pe tutplus. Foarte bun. Sper sa reusesc sa le urmaresc pe toate pana imi expira cele 14 zile. Cand am vrut sa platesc subscriptie anuala, din pacate nu am putut, ca zic astia de la ING ca tutplus nu are certificat potrivit, asa ca nu am putut plati… Cand o sa am nervi, o sa vad cum rezolv si aspectul asta cu birocratia romaneasca.

2 Likes

Motivul pentru care la munca nu pot implementa TDD, este ca, in primul rand, nu stiu de unde sa incep. Sunt aplicatii multe si complexe, scrise in CI, versiune veche. 1.7. PHP 5.1… Se foloseste foarte mult javascript, iar despre TDD in javascript nu am citit nimic inca… se foloseste un framework destul de stufos, care nu stiu cum poate fi testat. E vorba de Extjs 3.4.
Tare mult as dori sa inteleg cum sa implementez asa ceva, sa pot sa propun eventual o schimbare de abordare. Insa nu pot propune ceva daca eu nu stapanesc la perfectie conceptele. Poate e doar in mintea mea… Oricum, mai am de citit.

Pe mine m-a ajutat destul de mult cartea asta în a înțelege cum aș putea îmbunătăți cod vechi.

Pentru a înțelege și mai bine cum se pot scrie teste (nu-ți imagina că am ajuns un guru, ci doar că înțeleg mai bine decât înțelegeam înainte!), m-au ajutat și (în ordine aleatorie):

Ce m-a enervat extrem de mult a fost modul în care sunt făcute articolele (și chiar cărțile!) ce tratează unit testing:

  1. prima parte (introducere): testele sunt foarte utile deoarece… (și se explică de ce sunt bune testele; de obicei o discuție abstractă ce ar putea fi identică peste tot)
  • restul articolului/cărții tratează instalarea xUnit, aserții de bază ($this->assertTrue( $foo ) ) și… cam atât. Nimic despre cum ar trebui scris codul, despre cum s-ar putea implementa principiile SOLID sau despre alte lucruri utile. Nu dau vreun link, pentru că majoritatea resurselor găsite sunt așa, deci nu e foarte greu să cauți :smiley:

Acum, la mai bine de doi ani de când a început să mă intereseze acest workflow, am terminat prima aplicație la care am practicat TDD cap coadă (în JS; a ajutat foarte mult și faptul că aveam un deadline foarte lejer); a durat mult, dar rezultatul este satisfacător. Fun fact: fiind prima aplicație făcută în acest fel, evident că am avut părți ce n-am știut să le testez (sau pur și simplu părea foarte complicat). Când au început să apară primele bug-uri, am observat o chestie foarte interesantă: am avut bug-uri doar pe codul netestat. Prin urmare, când apărea un bug, scriam teste, rezolvam bug-ul (am avut două cazuri în care știam cum aș fi putut să rezolv problema în două minute, dar m-am încăpățânat să scriu teste întâi și m-am întins pe o zi)


Despre cum să fii primul care adoptă tehnica asta a scris tot @patkoscsaba :wink:

1 Like