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):
- Laravel Testing Decoded by JeffreyWay [Leanpub PDF/iPad/Kindle]
- Refactoring Legacy Code Code Tutorials | Envato Tuts+
- Test-Driven PHP Code Tutorials | Envato Tuts+
- http://cleancoders.com/ (sunt câteva episoade în care se prezintă TDD în practică)
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:
- 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
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 