"rendesen TDD szerint kódolni" kimondom nyiltan. en nem hiszek a tdd-ben. Vegeredmenyben az erdekel, hogy azt csinalja-e a feature, amit elvarnak tole, fejlesztes kozben a folyamatot tesztelem nem az egysegeket.
Egy valamire valo fejlesztes soran 3-4 modulbol 10-20 fajl van megnyitva atlagosan. Ha ugyanennyi unit teszt is meg lenne nyitva valoszinuleg megorulnek.
Arrol nem is beszelve, hogy fejlesztes kozben elo-elo fordul, hogy ujra/at kell szervezni a kodot, tehat allhatnek neki a teszteket is atszervezni, total feleslegesen. Szoval engem szemely szerint hatraltat, megneheziti az alkotoi szabadsagomat :)
De olyan is elofordul, hogy nem magam miatt kell refaktoralni, hanem mert mondjuk 1-2 ember reviewzta a kodot, es valamit igazitani kell, vagy csak egesz egyszeruen konfliktol a ribe'z.
A fentiekbol illetve abbol, hogy a teszt irasakor meg kell probalni eltorni a kodot adodik, hogy tenyleges munka helyett olyan kod eltoresen agyalok, ami lehet, hogy nem is lesz resze a vegleges valtozatnak (vagy tdd-ben az eltores az kulon iteracio?). Ha ezt megszorzom azzal, hogy a tesztek eltekintve a ritka kiveteltol mindig terjedelmesebbek, mint az alany, sok esetben meg side effect is van bennuk amit kezelni kell, akkor vegeredmenyben (nekem) az jon ki, hogy ertekes fejlesztoi eroforrasokat emeszt fel TDD-vel fejleszteni, mikozben a vegeredmenyt egyben igyis-ugyis tesztelni kell.
Non plusz ultra, hogy az en agyamban sincs ingyen a context switch :D A fejemben van egy tobb modulon meg 3rd partyn at vezeto komplex funkcionalitas, es mielott lefejlesztenem/kiprobalnam, hogy egyaltalan mukodik-e, alljak neki micro managelni sz@ros kis egyseg teszteket.
Ahogy mi csinaljuk ("dobozos" sw kalkulalhato relese ciklussal):
Megelozo meeting(ek) soran megbeszeljuk hogyan illesztjuk be az uj funkcionalitast, milyen nagyobb egysegek kellenek bele. Architekturalis donteseket csapat szinten hozunk, viszont a konkret implementacio a feature fejlesztojere van bizva.
Beveretjuk a featuret a kodba, 1-3 ember atnezi alaposan a pull requestet, minel elobb, akar "fel keszen" is bemegy a masterre, hogy egyutt eljen a tobbi koddal.
Masteren aztan hasznalja a tobbi fejleszto, futnak integration tesztek, meg e2e tesztek, meg ui tesztek, meg a mock integratios tesztek, meg azt se tudom milyen tesztek vannak meg, nem is az en feladatom igazan :) (esetunkben nem csak a mi szoftverunket kell tesztelni, hanem az azzal telepitett hadoop clustert is).
Aztan mikor a vegehez kozeledik a fejlesztes, akkor dedikalt idoben irunk unit teszteket, hogy a kovetkezo fejleszto, nehezebben tudja eltorni a meglevo funkcionalitast, de addigra mar csak vegleges kodra kell irni teszteket, aminek az ido koltsege nyilvan toredeke annak, mintha vegig tutjgatni kellett volna minden egyes egyseget. Aztan 1-2 ember megnezi a tesztekrol keszult pull requestet.