Test Driven Development, a kezdetek

Sok esetben alapos szemléletváltozás szükséges ahhoz, hogy a tesztvezérelt fejlesztést előnyeit ki tudja használni a fejlesztő. Legalább annyi támogatója van, mint ellenzője. Sajnos feltételezésekbe kell bocsátkozzak, de szerintem az ellenzők egy jó része nem értette meg mire is való a TDD, és sokszor a lelkes kezdők is hasonló sorsra jutnak. A TDD kulcsszava a tervezés nem pedig a tesztelés. Járjuk körül egy kicsit, hogy miért is létezik ez az egész, hogy végül (reményeim szerint) használható alapot adjak azok kezébe, akik megpróbálkoznak a TDD-vel. Ez természetesen azzal jár, hogy néhány vitatott kérdésben elkötelezzem magam valamelyik oldal mellett.

Jól működő, könnyen bővíthető alkalmazás, szolgáltatás, stb. kell ahhoz, hogy a cég tulajdonosai élvezhessék a szoftverfejlesztés által megvalósuló ( jól megérdemelt ) hasznot. Ehhez biztosítani kell a létrehozott szoftver minőségét. Egyik ilyen módszer a tesztvezérlet fejlesztés. Minek és milyen minőségét fogja biztosítani az szerepeljen a következő sorokban, de előtte még oszlassunk el néhány tévhitet.

Bizonyos szabályokat be kell vezetni ahhoz, hogy arra használjuk a TDD-t amire kell. A TDD egy fejlesztési módszer, nem pedig a szoftver tesztelésére használható eszköz. A módszer alkalmazásához teszteket is kell írnunk, azok pedig egység teszek (Unit test) lesznek. Mindenhol futtatható kell hogy legyen. Munkahelyi gépeden, otthoni gépeden, vonaton, Hősök terén. Bármilyen sorrendben lehessen futtatni a különböző teszteket. Külső függőségek nélkül, mint  például hálózat, vagy fájlrendszer. A teszteseteknek csak akkor kéne változniuk, ha a kódnak is változnia kell. Nem minden rendszer esetében használható ez a módszer.

A fejlesztési folyamat négy lépésre bontható:

Feladatok meghatározása:

     Ebben a lépésben az ügyfél igényeknek megfelelő funkcionalitást kell feladat meghatározássá alakítani teszt esetek formájában. Meg kell határozni, hogy mit kellene tennie a rendszernek. Fontos, hogy nem azt kell itt kitalálni, hogy az adott fejlesztő hogyan valósítsa meg az adott feladatot, hanem hogy mit kell majd megvalósítani. A mit meghatározása által a fejlesztő is jobban megérti a feladatot, kisebb a félreértés lehetősége. A teszteset megírása után következik a megvalósítás.

Megvalósítás:

     Ezután következik a hogyan valósítsuk meg az előre definiált feladatot. Azután meg is kell valósítani. A megvalósításnak kéne a legkönnyebb résznek lennie, ha mégsem könnyű akkor a következő problémák fordulhattak elő. Túl nagy feladatot határoztunk meg az előző lépésben, így az a feladat, hogy kisebb feladatokra bontsuk. Felmerül a kérdés, hogyan lehet könnyű a megvalósítás, ha előtte még egy libet is el kell előtte készíteni? Ilyenkor az adott lib feladatait kell meghatározni úgy, hogy a fejlesztők lesznek az ügyfelek és a ő igényeiket kell kielégíteni, és TDD alapján lefejleszteni.

     Ha nem nagy lépésről van szó de mégis nehéz megvalósítani, akkor refaktorálni kell az adott részt. Ez lehet azért mert koszos a kód, vagy nincs jól megtervezve, stb. (A refaktorálás viszont egy külön történet, melyet meghagyunk egyelőre más blogoknak.)

Ellenőrzés:

     A megfelelő eszközzel le kell ellenőrizni, hogy sikeresek lettek-e a tesztek. Ennek gyorsnak és könnyűnek kell lennie. (A tesztek nem futhatnak néhány mp-nél lassabban, akkor már nagy a gond, ha több idő kell.) Ezáltal folyamatosan ellenőrzött, tervezett és fejlesztett lesz a kódunk.

Tisztítás:

     Ha elértük, hogy sikeresen lefussanak a tesztek, akkor jön a kód tisztítása. A működő kódot átnézzük, a duplikációkat eltüntetjük. Beszédesebb neveket választhatunk a változóinknak. Mivel az ügyfél számára fontos funkcionalitás már le van tesztelve, ezért bátran megtehetjük mindezt, ugyanis ha például elgépeljük valahol az új változónevet, akkor rögtön jelez a teszt, hogy hiba van. Esetleg túl nagy lett a függvény, akkor több kisebb függvényre szétbonthatjuk, stb. Ettől tisztább és karbantarthatóbb lesz a kód.

Figyeljük meg, hogy az összes lépés megfeleltethető a tervezés egy-egy részének. A meghatározott feladatok automatizálásának köszönhetően lehetséges, hogy kis biztonságos lépésekben történjen a rendszer felépítése és tervezése. Segíti a feladat megértését, rákényszerít a könnyű megvalósíthatóságra a folyamatos tisztítás és újratervezés segítségével.

TDD előnyei:
- Refaktorálást segíti.
     - Bátrabban módosítjuk az elkészült kódot.
     - Könnyebb egy tesztelhető kódot refaktorálni ( a tervezés miatt ).
- Megmutatja, hogy hol hasalt el a kód.
- Az is segítség lehet, hogy hol nincs hiba.
- Segít tesztelhetővé tenni az alkalmazást.
- Rákényszerít, hogy egy függvény ne foglalkozzon sok mindennel.
- Csak olyan kódot írsz, ami a teszthez kell.
- Előre kell tervezni.
- Elvileg jobban is lesz ettől megtervezve. :)
- Gyors, folyamatos visszajezést kapsz a funkció állapotáról.
- Az utolsó változtatásodnál ha érintett egy régebben megírt függvény, akkor azt pontosan jelzi.
- Jobban ellenőrizhető a munka.
     - Van, hogy egy funkciónak nincs látható eredménye egy hétig. Ezzel szemben a TDD-nél naponta meg tudod mondani, hogy mennyi sikeres tesztet tudtál írni.
- Segít megérteni a feladatot a példákon keresztül.
- Időcsökkentő tényező a hibajavításnál és a refaktorálásnál.
- Hibajavításnál segíthet pontosabban megjelölni a hiba helyét.
- Akár dokumentációként is szolgálhat a teszt. Példakódnak tekinthető. ( Python doctest erre az elképzelésre épül. )
- Biztosítja, hogy az új kód nem érint más tesztelt egységet.
- Vannak emberek akiknek ez lelkisegély.
     - Örül, hogy de jó, sikeresen lefutott a teszt.
     - Bizonytalanoknak mentsvár. :)
     - Vannak akik ettől lesznek motiváltak és büszkék lesznek a munkájukra.
- Vitatkoznak arról, hogy melyik a hatékonyabb módszer, a TDD vagy a kód felülvizsgálat.
     - Szerintem a kettő együtt hatékony, egyik nem helyettesítheti a másikat.
- Ha nincs TDD, akkor gyorsabban kész lesz, de nehezebben módosítható később.
- A TDD tisztítás része pl. kódfelülvizsgálatnak is tekinthető.
- Stabilitást elősegítheti.

Hátrányok:
- Nő a fejlesztési idő. (Refaktornál csökken.)
     - Bevezetésekor drasztikusan.
- Ha nem tiszta, hogy mit kell tenni az adott feladattal könnyen írhatunk rossz tesztet, amit át kell majd írni. (Újabb időnövelő tényező.)
- Menet közben történt koncepcióváltásnál (létezik ilyen), könnyen kukába mehet az egész. (Újabb időnövelő tényező.)
- Sokan azt hiszik ettől hibamentes lesz a program működése.
- Nem csodafegyver. A rendszer tesztelésének (minőségbiztosításának) csak egy kis részét kéne, hogy képezze. (Accaptance test, integration test stb. mellett)
- A unit test csak annyit jelent, hogy önálló kis részek jól működnek.
- Csak tapasztalt fejlesztőkkel érdemes használni.
- A tervezést nem mindig lehet úgy alakítani, hogy az megfeleljen a TDD-nek.
     - Adatstruktúrák (közvetett módon) és "black box algoritmusok" tesztelésére jó.
     - Hálózattal, fájlrendszerrel kapcsolatos dolgok kilőve.
- Páros programozásban lenne érdemes használni.
     - A tesztek írása unalmas lehet egyesek számára. Nagy fegyelemre lenne szükség.
     - Nehéz belerázódni, ezért arra a következtetésre jutnak, hogy semmi értelme.
     - Nehezebben történik meg, hogy egy feladat megoldásának hevében megírod az összes feladatot egy teszt segítségével. :)
     - TDD-ben tapasztalt párral lenne a legideálisabb.
     - A páros programozás előnyeit pedig még nehezebben lehet megértetni a managerekkel. :)
- Nagy lelkesedés szükéséges az elején.
     - Ha írsz hat tonnányi tesztet, amiről kiderül, hogy semmit nem ér akkor biztosan szükség lesz rá.
- Nehéz megmagyarázni a managereknek, hogy az elején miért tart ennyi ideig a fejlesztés.

A tesztelés legyen veletek.