Test Driven Development

A Test Driven Development, vagy magyarul teszt vezérelt fejlesztés egy olyan szoftverfejlesztési folyamat, ami egy nagyon rövid fejlesztési ciklus ismételgetésén alapul, tehát a követelményeket speciális tesztesetekként fogalmazzuk meg, a kódot pedig ehhez mérten írjuk meg, így az át fog menni a teszten. Ez tökéletes ellentéte a "hagyományos" szoftverfejlesztésnek, ami megengedi olyan kódrészletek meglétét is, amelyek nem felelnek meg teljesen a követelményeknek.

A TDD összefüggésben áll az extrém programozás koncepciójával, miszerint először teszteljünk és ha minél többet tesztelünk, annál több hibát tudunk kiküszöbölni a kódban.

A TDD ciklusa:

1. Teszt hozzáadása
   TDD esetén minden új funkció a hozzá tartozó teszt megírásával kezdődik. Olyan tesztet kell írni, amely tömören és pontosan meghatározza az új funkciót, vagy a már meglévő javítására szánt funkciót. A teszt írásához értelemszerűen meg kell érteni a funkció specifikációját és követelményét. Ezeket a felhasználási esetek (use case) és a felhasználóval történt beszélgetések alapján pontosan meg lehet határozni.

2. Minden korábbi teszt futtatása, hogy kiderüljön, az új teszt megbukik-e
   Ez mutatja meg azt, hogy a tesztkihasználtság jól működik. Az új teszt új kód bekerülése nélkül nem fog sikerrel járni, mert még nem létezik a kívánt viselkedés, és ez megfelelően kiküszöböli annak a lehetőségét, hogy az új teszt selejtes legyen és minden esetben átmenjen a teszten. Az új tesztnek kudarcot kell vallania a várt eredmények alapján. Ez a lépés növeli a magabiztosságot az új tesztek megírásával kapcsolatban.

3. Kód írás
   A következő lépés olyan kód írása, amely alapján a teszt sikeres lesz. Az ebben a szakaszban írt kódnak nem kell tökéletesnek vagy elegánsnak lennie. Egyetlen célja az itt megírt kódnak, hogy a teszt sikeres legyen. Fontos, hogy ebben a lépésben ne kerüljön be olyan kód, amely meghaladja a teszt által ellenőrzött funkciókat.

4. Minden teszt újbóli futtatása
   Ez a lépés ellenőrzi, hogy az összes tesztelési eset működik, így biztosak lehetünk benne, hogy az új kód megfelel a követelményeknek és nem ront a meglévő funkciókon. Ha ebben a lépésben hibára futna a teszt, akkor a kódot addig kell módosítani, amíg sikerrel nem teljesíti a tesztet.

5. Kódszépítés, refaktorálás
   Ha az előző lépésben megbizonyosodtunk arról, hogy a kód megfelel a követelményeknek, akkor biztonsággal állhatunk neki a kód szépítésének és átdolgozásának, refaktorálásának.

TDD az állatorvosi lovon túl

A TDD munkamenetét és mibenlétét általában egy állatorvosi ló példáján keresztül szokták bemutatni. Ezt a könyvben nem szeretném megtenni, mivel egy példából nem lehet messzemenő következtetéseket és igazságokat levonni a módszerrel kapcsolatban, főleg nagyobb méretű (értsd: nem hobbi) projektek esetén.

A tapasztalatom szerint a TDD-nek van létjogosultsága és helye, de nem mindenhol. Ha a specifikáció hiányos, vagy menet közben változik, akkor a TDD kifejezetten káros tud lenni. Olyan esetekben, ha tudjuk jól, hogy a rendszernek egy adott bemenetre mit kellene reagálnia (pl. szabványok, RFC-k, számítások implementálása), akkor igen is hasznos tud lenni a TDD.

A TDD akkor tud még nagyon fájó pont lenni, ha a rendszer teszt piramisa nem egészséges és jóval több system test és integration teszt van, mint egységteszt. Ebben az esetben, ha a TDD bevezetése a cél, akkor a meglévő teszteket és a kódot kell először úgy gatyába rázni, hogy az egy egészséges teszt piramist mutasson. Ha enélkül kerül bevezetésre (pl. menedzsment nyomására) a TDD, akkor többet fog ártani, mint használni. Szimplán azért, mert ha a projekt kivitelezői nem látják be, hogy a tesztelés nem egészséges, akkor valószínűleg nem egy pozitív és támogató mentalitással fognak nekiállni a tesztek megírásának.