Pedig az a TDD lenyege, hogy eloszor (unit) tesztet irsz, es utana a kodot (hogy "a piros zoldre valtson" - ez egy pszichologiai jutalmazasi effekt). Az atyauristen agile-szent profeta mr. Unclebob szerint az idealis ido, ami teszt/kod iras valtas kozben eltelik, az masodpercekben (!) merheto. Ez kizarolag unit teszteles eseten lehetseges.
Volt mar szo rola, de az ismetles sosem art:
https://rbcs-us.com/site/assets/files/1187/why-most-unit-testing-is-was…
https://rbcs-us.com/site/assets/files/1191/segue.pdf
TL;DR: sok problema van a TDD-vel, meg ugy altalaban a unit tesztek eroltetesevel mindenre, de talan a legfontosabb tanulsag ez: mibol gondolod, hogy a teszt irasakor okosabb vagy, mint a kod irasakor?
A legegyszerubb fuggvenyek eseten is nagyon konnyu olyan unit teszteket irni, amelyek tokeletes lefedettseget adnak, megsem mutatjak ki a legegyszerubb hibakat sem. Es akkor meg nem is beszeltunk a mock-erdovel korulvett, a kodnal nagysagrendekkel hosszabb es bonyolultabb teszttel rendelkezo fugvenyekrol/osztalyokrol, amelyek tenylegesen nem tesztelnek semmit, viszont 10-szeresere novelik a fejlesztes koltseget.
Csak azert, mert TDD-zel meg unit teszteket irsz, meg ugyanugy gondolkodnod kell, ezt azonban a TDD igyekszik egy nagyon korlatolt mederbe terelni. Szamos problema van meg vele, akit erdekel, olvassa el a fenti cikkeket.
Mi az, amit TDD helyett erdemes (lenne) hasznalni: peldaul QuickCheck-alapu generalt teszteket, es termeszetesen magasabb szintu, business use-case-eket lefedo, lehetoleg end-to-end teszteket, amelyek lehetnek automatizaltak, de lehetnek akar manualisak is (nem mindig eri meg automatizalni - ez is egy tipikus TDD hiba).