Egyre több dolgot TDD módon írok meg. Ami szembetűnő a korábbi, először implementálok aztán ha van rá idő írok hozzá tesztet (nem fogok) módszerhez az a következő:
-Sokkal kevesebbet, nagyon sokszor egyáltalán nem debugolok. Ez eszement sok időt spóroló tevékenység, gyűlölöm, amikor 2-3 percet is nyomkodok, mire eljutok a betegnek vélt ponthoz a debuggerben. Ott aztán sokszor kilép a debugger (pont timeoutolt a web worker process), release kód miatt nem mutat változókat, továbbléptetem, aztán kezdhetem elölről (lehet mozgatni a current pointert, de ha már okoztunk mellékhatásokat hiába megyünk vissza), stb. Szeretem az advanced debuggung témát, de utálom az időt vele feleslegesen tölteni.
-A GUI-t alig indítom el, ezáltal megint nagyon sok időt takarítok meg.
-Az implementált dolgaim azonnal mennek, amikor a GUI-t is elindítom, már csak élvezni kell az eredményt.
-Hamarabb készen vagyok a feladattal. Tudom, ezt nem lehet objektíven mérni, mert nincs mihez viszonyítani. De az első két pont miatt érzésre annyi időt megtakarítunk, ami felülmúlja a tesztekre szánt időt.
Igazából a TDD nem is a tesztelésről szól. Ez komplexitás és félelem kezelés. Arról szól, hogyan implementáljuk egy bonyolult feladatot sok kicsit változaton keresztül úgy, hogy ne őrüljünk bele, ne legyen sok kudarcunk. Az már csak egy plusz, hogy sokkal jobb lesz a kódminőség.
Could you hire me? Contact me if you like what I’ve done in this article and think I can create value for your company with my skills.
LEAVE A COMMENT
5 COMMENTS
Esetleg még az NCrunch használata és fordítani sem kell. Nagy solutionnél sok-sok projekttel lassú lesz, de elég sokáig használható.
http://www.ncrunch.net/
A TDD mar kb 4-6 eve itt van, en kb 4 eve hasznalom folyton, csodalom, hogy csak most jutottal el ide, eleg alap dolog :D Ha mar belejottel TDD-be, egy lepessel tovabb mehetsz BDD-re, en mar ezt tolom 1.5 eve.
Azért nyilván csak korlátok között lehet használni, gondolom.
Próbált már valaki TDD-vel SharePoint “akármit” fejleszteni (lehet persze, hogy mockolva meg modell alapon minden ok, aztán minden része dobja a hátast SP alatt…)? :) Vagy akár unit test-eket írni hozzá, ami után ki lehet jelenteni, hogy készen vagyunk! :)
Másik meglátás, a TDD is csak pont annyira hatékony, mint amennyire jó a programozó (ha nincs fantáziája, akkor a test case-ek megírására sincs fantáziája)
Richárd: kösz a tippet, használom egy darabig, aztán leírom, mit gondolok róla, elsőre tetszik.
Tamás: lassan érő típus vagyok. BDD-t megnézem, köszi.
KKető: igen, a tdd nem mindenhol vethető be kényelmesen, én is filózok a saját legacy kódjaim továbbfejlesztésekor hogy vezessem be. Annak idején VS addint írtam TFS-hez, ott se tudtam rendesen kimockolni mindent, kínlódtam vele sokat.
Én sajnos csak mostanában ismertem meg, eddig “féltem” tőle. Tetszik, és ha lenne egyszemélyes projektem akkor használnám.
De azt látom minden projekten (én elég sűrűn váltok projektet :) ) hogy a fejlesztők még “sima” unit teszteket is alig írnak, mert vagy nem tudják hogy hogyan kell és mit érdemes, vagy nincsenek rákényszerítve. Vagy nem tudom, nem látják az értelmét. Pedig már 2012-t írunk, érthetetlen. És nem kis projektekről van szó, több mint 30 EZER embernapot öltek eddig bele, szerintem megérte volna :)
A TDD egy más felfogást igényel, a felsorolt előnyök mellett az egyik power szerintem az hogy legalább rákényszerül az ember arra, hogy átgondolja mit is kell implementálni és hogyan. Valóban szükség van-e arra a metódusra, és annak valóban úgy kell-e viselkednie.
Ekkora szemléletváltás viszont sok türelmet és időt(pénzt) igényel a vezetés részéről, mert amíg megtanulják és átállnak az sok idő. Szoros határidőkkel, 70-80 fejlesztőt “átnevelni” egy elég komoly misszió. Márpedig akkor van értelme ha egy 10-es csoportból nem csak 1 ember TDD-zik rambóként. Magyarul azt akarom mondani ezzel, hogy egy multinál az excelben az aktuális számok sajnos néha fontosabbak mint a hosszútávra tervezés. Bár ez ott felsőbb szinteken lehet hogy bonyolultabb és én nem vagyok képes megérteni :)