Agilis Meetup élménybeszámoló
Április 15-én, az Agilis Meetup keretében volt lehetőségem meghallgatni Fejes Péter előadását, ami igen informatívra, de annál is szemléletesebbre sikerült. Nem volt egészen ismeretlen előttem az egységtesztelés (unit test) fogalma, mégis azon kaptam magam, hogy meglepődve látom először megszületni a tesztkódot, majd hozzá a tényleges alkalmazást.
A példában egy query stringet feldolgozó osztály elkészítése volt a feladat, amit aztán természetesen refaktorálni is kellett. Azt hiszem, az egész előadás legmeggyőzőbb pillanata az volt, amikor a temérdek szándékos és jól megkoreografált hiba után az egyik műveletnél némi figyelmetlenség folytán egy másik függvény regressziót szenvedett a módosításoktól, és ezt a unit test szépen ki is jelezte. Mondanom sem kell, hogy az egyébként igen nehezen kivédhető hibatípus felderítése és javítása másodpercekben alig volt mérhető azzal szemben, hogy adott esetben ezt csak egy járulékos hiba kapcsán fedeztük volna fel néhány tíz perc debugger nézegetés árán.
Az előadás során fény derült a TDD módszer előnyeire, és az azt követő vita folyamán a vele kapcsolatos nehézségekre is. Hatalmas előnye, hogy a fejlesztőkörnyezetbe integrálva a tesztek szinte transzparensen futnak, és némi odafigyeléssel és energiaráfordítással lehetőséget nyújtanak arra, hogy az elemi építőkockákban ne torlódjanak össze a hibák, amiket később sokkal-sokkal nehezebb felderíteni. Ezzel szemben áll, hogy a tesztkód gyakran ugyanakkora, mint a programkód, és ezt az oldalt egy percig sem lehet hanyagolni. Az egész csapatnak egyszerre át kell állnia a TDD módszerére, különben a védelmi háló lukas lesz, a hibák pedig átcsúsznak rajta. Pontosan ezért nehéz feladat a bevezetése olyan helyzetben, ahol a csapat egy része vagy a menedzsment nincs meggyőzve a hasznosságáról, vagy a projekt már előrehaladott állapotban van, és tetemes a tesztkód nélküli kódbázis.
Az előadás egy másik lényeges mondanivalója, amiről reményeim szerint a Budapest Agile Meetup Group keretein belül fogunk még előadást hallani, az az integráció tesztelés volt. Zsuffa Zsolt, a házigazdánk kiemelte, hogy nem szabad összekeverni a TDD módszerét az integráció teszteléssel. Ez utóbbi, mint ahogy a neve is mutatja, nem az egységek működését teszteli, hanem hogy a végső környezetben, adatbázis háttérrel, éles API-val stb. hogyan fog működni az alkalmazás.
Összefoglalva az előadást, az agilis módszerek egyfajta kontrollt adnak a hibák felett, nem engedik elburjánzani őket, és ezáltal a határidőt is betarthatóbbá teszik. Ezúton is szeretnék gratulálni az Agilis Szoftverfejlesztők Egyesületének a lelkes és lelkiismeretes munkájáért, és kérem, hogy folytassák azt, mert nagyon nagy szükség van rájuk. Ti meg, kedves Weblabor olvasók, menjetek el az előadásaikra, és terjesszétek a profi szakmai módszereket kis hazánkban.
■ A példában egy query stringet feldolgozó osztály elkészítése volt a feladat, amit aztán természetesen refaktorálni is kellett. Azt hiszem, az egész előadás legmeggyőzőbb pillanata az volt, amikor a temérdek szándékos és jól megkoreografált hiba után az egyik műveletnél némi figyelmetlenség folytán egy másik függvény regressziót szenvedett a módosításoktól, és ezt a unit test szépen ki is jelezte. Mondanom sem kell, hogy az egyébként igen nehezen kivédhető hibatípus felderítése és javítása másodpercekben alig volt mérhető azzal szemben, hogy adott esetben ezt csak egy járulékos hiba kapcsán fedeztük volna fel néhány tíz perc debugger nézegetés árán.
Az előadás során fény derült a TDD módszer előnyeire, és az azt követő vita folyamán a vele kapcsolatos nehézségekre is. Hatalmas előnye, hogy a fejlesztőkörnyezetbe integrálva a tesztek szinte transzparensen futnak, és némi odafigyeléssel és energiaráfordítással lehetőséget nyújtanak arra, hogy az elemi építőkockákban ne torlódjanak össze a hibák, amiket később sokkal-sokkal nehezebb felderíteni. Ezzel szemben áll, hogy a tesztkód gyakran ugyanakkora, mint a programkód, és ezt az oldalt egy percig sem lehet hanyagolni. Az egész csapatnak egyszerre át kell állnia a TDD módszerére, különben a védelmi háló lukas lesz, a hibák pedig átcsúsznak rajta. Pontosan ezért nehéz feladat a bevezetése olyan helyzetben, ahol a csapat egy része vagy a menedzsment nincs meggyőzve a hasznosságáról, vagy a projekt már előrehaladott állapotban van, és tetemes a tesztkód nélküli kódbázis.
Az előadás egy másik lényeges mondanivalója, amiről reményeim szerint a Budapest Agile Meetup Group keretein belül fogunk még előadást hallani, az az integráció tesztelés volt. Zsuffa Zsolt, a házigazdánk kiemelte, hogy nem szabad összekeverni a TDD módszerét az integráció teszteléssel. Ez utóbbi, mint ahogy a neve is mutatja, nem az egységek működését teszteli, hanem hogy a végső környezetben, adatbázis háttérrel, éles API-val stb. hogyan fog működni az alkalmazás.
Összefoglalva az előadást, az agilis módszerek egyfajta kontrollt adnak a hibák felett, nem engedik elburjánzani őket, és ezáltal a határidőt is betarthatóbbá teszik. Ezúton is szeretnék gratulálni az Agilis Szoftverfejlesztők Egyesületének a lelkes és lelkiismeretes munkájáért, és kérem, hogy folytassák azt, mert nagyon nagy szükség van rájuk. Ti meg, kedves Weblabor olvasók, menjetek el az előadásaikra, és terjesszétek a profi szakmai módszereket kis hazánkban.
Kombót akarok
Több is van
Megéri-e automatizált teszteseteket készíteni?