TDD a megoldás mindenre (?)

Minicube

Sziasztok, az én nevem Papp Krisztián és ez pedig a minicube podcast második epizódja!

A mai témánk nem más, mint a TDD, azaz test driven development. Nem sok más olyan téma van, ami ennyíre megosztja a fejlesztői társadalmat, aminek egyik oka az, ahogy mindezt hirdetik. Kicsit olyan, mint a kamu hirdetések, amikkel találkozhatunk a neten: egy egyszerű trükk, amivel megszabadulhat a kilóktól. Három egyszerű lépés, amivel igazán profi fejlesztővé válhatsz. Ugye, hogy így hangzik sokszor? Nincs más dolgod, mint hipp-hopp elsajátítani a TDD-t és minden gondod megoldódik.

Na de tényleg így lenne? És ha igen, akkor miért nem csinálja már mindenki?

Nos leginkább azért, mert ezt a fajta módszertant - ami egyéni, tehát mindenki maga dönti el, hogy használja-e, ellentétben pl a scrummal -, nem könnyű elsajátítani. Maga a tesztelés is egy olyan témakör, ahol habár rengeteg anyag kering a neten, piszok nehéz olyat találni, ami tényleg jó és nem móricka példákkal akarja átadni mindezt. Ha mindezt megfejeljük a TDD-vel, akkor garantált, hogy valami olyat kapunk, amivel később megutáljuk nemhogy a TDD-t, de magát a tesztelést is.

Na de mi is ez az egész TDD? Nem kell túl sok időt eltölteni a szakmában, hogy az ember szembetalálkozzon a fogalommal, de akinek ez még kimaradt, akkor gyors elmondom. Három szabálya van: nem írhatsz addig éles - tehát nem teszt - kódot, amig nem írtál hozzá egy tesztet, ami jelenleg törik, és épp ki akarod javitani. Nem írhatsz annál több tesztet, mint ami épp el fog törni, ebbe beleértjük a forditási hibákat is. A harmadik szabály pedig, hogy csak annyi éles kódot írhatsz, amivel épp megjavitod a tesztet, ami épp törik. Igy elolvasva is kapizsgálhatjuk, hogy mi volt az egyik legfőbb oka annak, amiért nem ugrott rá a szoftverfejlesztő közösség rögtön erre.

Teljesen más workflow ahhoz képest, amit a legtöbben megszoktak. Na meg az első gondolat az lehet, hogy miért írnék tesztet valamíre ami még nem is létezik? Tegyük fel, hogy valahogy túltettük magunkat ezen. Megkaptunk egy egyszerű feladatot, pl egy elfelejtett jelszó funkciót. Mindent mi kezelünk, Semmi sso, keycloak meg hasonló finomság. Ott van előttünk megnyitva az IDE, rákattintunk, hogy új tesztet akarunk létrehozni.. és belefutottunk az első problémába. Mi legyen a neve a fájlnak? Hát lévén az elfelejtett jelszót akarjuk tesztelni, a forgotpasswordtest elég jónak tűnik, nem? Első akadály legyőzve, következő rögtön jön utána: mi legyen a tesztmetódus neve? Valamit oda kell neki írni, hiszen anélkül nem tudunk törő tesztet csinálni. Hát azt akarjuk, hogy működjön, nem? Akkor legyen "itWorks". Ezután pedig jön az, hogy mégis mi bizonyitja, hogy működik? Hát kiküldi az emailt, amíre ha rákattintunk, akkor utána be tudjuk állítani az új jelszót, amivel utána be tudunk lépni. Ezután pedig megprobáljuk ezt az egészet belezsúfolni egy tesztbe, amivel nemhogy a TDD-t, de a tesztelés egyéb szabályait is megszegtük.

Ehelyett meg kellene állnunk és átgondolni, hogy mik is azok a lépések, habár az imént jól össze lettek szedve. Na de a negativ esetekről se feledkezzünk meg, mi van pl. akkor, ha nincs is ilyen felhasználó, vagy hibás a token ami az emailből jön.

Persze itt a legtöbb fejlesztő már el is dobta a billentyűzetet, hiszen kinek van erre ideje? Itt van a feature, egy szusszra lefejlesztem egy óra alatt, utána kipróbálom, működik, akkor minek teszteket írni meg bajlódni ezzel az egésszel? Csak megtöri a flowt és nem is haladok vele. Erre a flowra majd kitérünk később.

Az egyik legtipikusabb válasz, hogy "csukott szemmel is megírom, annyiszor kellett már". Ezzel két probléma is van, először is ha már olyan sokszor megírtad, miért nem emelted még ki egy ujrahasználható modulba, valamint az, hogy valóban csukott szemmel csinálta.

Miért is? Amikor tesztek nélkül implementálunk valami nagyobb modult, a végén pedig kézzel végignyomkodjuk, az kb olyan, mintha egy sötét szobában kezdenénk legózni és csak a legvégén kapcsolnánk fel a villanyt, hogy lássuk mit is alkottunk. Ehelyett megtehetnénk, hogy minden kis apró darab felhelyezése után felkapcsoljuk a villanyt, hogy ellenőrizzük az eredményt. Ha nem tesszük, igen könnyen oda jutunk, hogy kicsit csárén áll a millenium falcon.

Ez nyilván csak akkor megy, ha az a bizonyos villany megvilágitja azt amin dolgozunk, a félhomály nem lesz elég. Tehát megbizható tesztek kellenek. Szintén fontos, hogy ne kelljen elindítani egy aggregátort minden alkalommal mikor fény kell, mert akkor a kutya se fog bajlódni ezzel. Tehát a tesztek gyorsan fussanak le és ne kelljen egy erőmű hozzá.

Persze én se állítom, hogy mindig TDD-ben fejlesztek, mert nem igaz. Ellenben egyre gyakoribb nálam is ez a hozzáállás. Ott éreztem először szükségét, mikor az alkalmazás elindítása hosszú perceket emésztett fel, emiatt végképp nem engedhettem meg magamnak, hogy minden apró módositás után újraindítgassam. Ellenben azt megtehettem, hogy amit tudtam lefedtem tesztekkel és azután próbáltam ki az alkalmazást egy utolsó smoke test erejéig. Ez először a test first volt, hiszen még nem úgy terveztem az alkalmazásom, kis lépésekben a tesztek mentén vezérelve. Csupán volt pár tesztem, amiket előre megírtam, hogy ezeket akarom letudni. Sokan itt megállnak, ami bőven elég, mert már ez is sokkal megbizhatóbb kódot eredményezhet. Viszont kellő önfegyelemmel ezt fel lehet darabolni kisebb lépésekre. Na az lesz az igazi TDD.

Akkor bele akarsz kezdeni? Tök jó! Ha már van egy olyan projekted, amihez akadnak tesztek, akkor nyert ügyed van, mert hozzá tudsz építeni így. Ha nincs ilyened, akkor először a teszteket kell bevezetni és elsajátítani. Ezt ajánlott olyan helyeken elkezdeni, amiket szívás az appon belül kézzel tesztelni. Pl valami speciális bónusz program, ami a fizetés utolsó lépésében jön fel, ha bizonyos termékek benne vannak a kosárban, visszatérő vásárlóknak, akik x hónapja nem vettek semmit. Egy ilyen teszthez megteremteni a valós körülményeket hatalmas szívás, nem?

Akkor képzeljük el, hogy fogjuk azt a kis kódrészletet ami eldönti, hogy bónuszprogramba kerültünk-e vagy sem és kódból meghívjuk, különböző körülményeket behazudva. Mi kell hozzá? Példányosítgatunk, függvényeket hívunk. A francba is, egész nap ezt csináljuk, ez a munkánk, nem? Ha ráérzünk ennek az ízére, akkor egyre több helyen fogjuk alkalmazni, amiket nehéz "végignyomkodni", később pedig azokat is amiket nem. Na és tudod mi a legjobb? Hogy ezt bármikor újra tudjuk futtatni, ha belenyúlunk a kódba. Na de ez miért nem elég? Miért kell ez a TDD is?

Emlékszünk még arra, hogy a TDD megtöri a flowt? Ez részben a lényeg, ugyanis az a bizonyos flow habár gyorsan eredményez működő kódot, semmi sem garantálja, hogy nincs benne hiba. Ráadásul tetemes mennyiség, így utólag a kutya se akar teszteket írni rá. Ehelyett rá vagyunk kényszeritve, hogy újra és újragondoljuk a problémát és annak megoldását. Ezzel ugye fixen olyan kódot készítünk majd, amihez vannak tesztek. Hiszed vagy sem, a tesztek nem a legfontosabbak itt, inkább azoknak a hozadéka. Ugyanis a tesztelt kód általánosságban jobb minőségű, modulárisabb. Miért? Mert az a kód, amit nehéz tesztelni, általában problémás. Itt ugye a folyamat részét képezik a tesztek és ahogy bővül a kód, feltűnik hogy nehezebb tesztelni és fogsz időben ellene tenni.

A lényeg tehát itt is a sokszor ismételgetett mondat, csinálni-csinálni-csinálni. Idővel ebbe is beletanul az ember és eljön az a bizonyos 'aha' élmény, ami után talán máshogy nem is akar az ember kódhoz nyúlni. Persze ahogy az elején mondtam, ez egy egyéni workflow, nem mindenki tudja magáénak. Ez persze nem megy könnyen, ugyanis a TDD az extreme programming, azaz xp környezetben született, amit elég nagy fegyelem jellemzett és megvolt a támogatás a TDD felé. Ez már nemigen jellemző, így akadnak helyek, ahol szinte esélytelen bevezetni.

Kérdés, hogy szükséges-e az adott projekten? Gondoljunk csak valami kis oldalra PHP-ban: egyik monitoron a kód, a másikon az oldal minden szerkesztés után egy oldalfrissités, mindez pillanatok alatt történik, így ha ugy nézzük az illető legalább egy ágat tesztel, még ha manuálisan is. Ez sok esetben még elég is. Micrositeoknál nem lesz semmi olyan amit érdemes lenne tesztelni, nem fogja továbbnőni magát a kód. Vagy mégis? Akkor ki fogja tovább gondozni? Benne mernéd hagyni az elérhetőséged a readme-ben a következő fejlesztőnek, vagy vállalnád hogy tovább fejleszted az oldalt?

Ezzel a gondolattal búcsúzunk, ez volt a minicube podcast, találkozunk legközelebb!

---

Our GDPR privacy policy was updated on August 8, 2022. Visit acast.com/privacy for more information.