Btw olyan nem letezik, hogy a legaprobb szinten megterevezed a feladatot, illetve letezik, kodolasnak hivjak. Amig a tervezesed nincs 100% fedesben a kodolassal, addig mindig lesznek apro (neha nagyobb) reszletek, amik implementacio kozben derulnek ki. Nalunk ha bejon egy ujabb feature requets, akkor annak altaban kell egy vegpont ami elindit egy async flow-t. Kell neki konkret flowt osszerakni, az flow lepesek neha helyi adatokat allitanak elo, neha 3rd partyval kommunikalnak. Ugyanazt a funcionalitast kell pl megvalositanunk 5 teljesen eltero cloud APIval (az egyik igy mukodik a masik meg ugy, az egyiknek kell valami parameter a masiknak nem), hasznalunk pl alul dokumentalt API-t, a kapott adatokat fel kell dolgozni, veges sok szamu hibat kell kezelni (amit mondjuk az a 20 API hivas general, amit elkuldunk egy flow alatt), stb. stb. Nem beszeltem meg arrol, hogy flow-k is hatnak egymasra (pl egy termination flow kiuti az upscale flowt), es mindent idenpotensen kell megcsinalni, hogy barmikor ujraindithato legyen barmelyik lepes. Elofordulhatnak konkurrens adatkezelesi issuek, amik papiron pl igen ritkan jonnek elo. Nem azt mondom, hogy lehetetlen teljes reszletesseggel megtervezni az egeszet, de ... beleoszulsz, mire minden kis reszletre ramesz, minden apro dolognak csainlsz POC-ot, hogy lasd pontosan hogyan mukodik. Es meg akkor is 100%, hogy elo fog jonni olyan dolog,ami kimaradt a tervezesbol. Itt bukik meg szerintem a TDD, hogy amikor elmondjuk hogyan mukodik meg mire valo, akkor jol hangzik, csak mikor egy komplex feladatot meg kell oldani, akkor ahelyett, hogy a problemat oldanad meg nekiallsz a rendszer kulonbozo pontjain fiktiv teszteket irni, meg olyan eseteken agyalni, amik lehet, hogy elo sem fognak jonni, vagy egy teljesen mas retegben kell kezelni a hibat. A tul sok teszt is hatrany. Szerintem a tesztek arra jok, hogy rogzitsek az egyseg mukodeset, es akik atirjak az adott funkciot ne tudjak az erdeti funkcionalitast elrontani, mert mar nem emlekeznek ra, vagy nem is ok irtak, igy sosem tudtak, hogy mukodik. Amig a fejleszto emlekszik a sajat kodjara (tipikusan fejlesztes kozben) addig kar megvedeni sajat magatol. A TDD sem ment fel az alol, hogy leteszteld kezzel, igen manualisan, hogy sikerult-e egyaltalan megodlani a problemat. A vegleges implementaciot a vegen toredek ido raforditasaval lehet tesztekkel lefedni.