A TDD (Test Driven Development) világa, I. rész: Bevezetés
A TDD módszertan egyáltalán nem számít újdonságnak (évtizedekkel ezelőtt már a NASA is alkalmazott a Mercury projektjében egy nagyon hasonló metodológiát), de igazi tündöklése a kétezres évek elején kezdődött az extrém programozás mozgalom keretein belül, ám sikere ellenére mégis sokaknak máig idegen téma. Ebben a cikksorozatban a célunk a TDD hogyanjait és miértjeit röviden ismertetni.
Mi az a TDD?
A TDD egy iteratív szoftverfejlesztési módszertan, amelyben egy új funkció implementálása előtt írjuk meg az ahhoz tartozó automatizált teszteket. Ez egy ciklikus folyamat, amely az alább ismertett lépésekből áll.
Elsőként létrehozunk egy új tesztet a hozzáadandó, még nem létező funkcióhoz. Ez a kulcslépés az egész ciklusban, ezzel arra törekszünk, hogy a fejlesztő még az első kódsor megírása előtt pontosan ismerje a létrehozandó funkció elvárt működését. Azonnal látni, hogy ezek a tesztek így nem csupán az automatizált tesztforgatókönyveket biztosítják a szofverünk számára, hanem egyfajta specifikációként, dokumentációként is szolgálnak.
A második lépésben lefuttatjuk az összes tesztünket, köztük az újonnan hozzáadottal, és ellenőrizzük, hogy az utóbbi elbukik-e. Ez a lépés tulajdonképpen az új tesztünk tesztje: azt nézzük meg, hogy nem lesz-e véletlenül sikeres anélkül, hogy bármennyi új kódot is hozzáadtunk volna a szoftverünkhöz. Ha mégis így alakul, akkor az elvárt új funkciót a szoftver már most is megvalósítja, azonban legtöbbször inkább arról van szó, hogy haszontalan tesztet írtunk, amely sosem bukik el.
Ha a tesztünk a vártnak megfelelően elbukott, érdemes munkához látni, és megírni pontosan annyi kódot, amely által a tesztünk sikeressé válik. Itt nem szükséges a tökéletes, vagy a legelegánsabb megoldásra törekednünk, az egyetlen lényeges mozzanat, hogy megvalósítsuk az új funkciót.
Amikor a tesztünk sikeres lett, a következő lépés a refaktorálás. Ezen a ponton biztosak lehetünk benne, hogy a módosított forráskód már megvalósítja a folyamat elején kitűzött funkcionalitást. A tesztünk innentől egyfajta védőhálóként szolgál, hiszen a kódot szívbaj nélkül refaktorálhatjuk, átszervezhetjük, elegánsabbá tehetjük; az új teszt által egy gombnyomással ellenőrizhető, hogy a programunk még mindig ugyanazt csinálja, amit eddig. (A fentiekben leírt folyamatot a szakirodalom gyakran Red. Green. Refactor. néven említi.)
Miért jó ez az egész nekem?
A TDD egyik legfontosabb előnye, hogy a kis lépésekben történő fejlesztést részesíti előnyben, ami a gyakorlatban általában sokkal produktívabb, mint a nagy lépésekben történő fejlesztés. Ha például megírsz valamennyi kódot, lefordítot és leteszteled, az automatizált tesztek elsőre szinte biztosan kidobnak pár hibát az új kódban jelen lévő bugok miatt. Nyilvánvaló, hogy ezeknek a bugoknak a megtalálása sokkal egyszerűbb tíz sor kódban, mint ötezerben. Ennek következménye, hogy minél gyorsabb a tesztek futtatására használt környezet, annál inkább csábító lesz kisebb és kisebb lépésekben haladni. Egyes ajánlások akár minden kb. tíz kódsor hozzáadása után javasolják az automata tesztek lefuttatását.
A másik, már korábban is említett óriási előny, hogy az előre megírt tesztek specifikálják és dokumentálják a szoftver működését. Mivel dokumentációt senki sem szeret írni, kódot viszont igen, ez egy nyerő szituáció a fejlesztők számára.
Ezután az általános bevezető után a következő részben a TDD-t övező tévhiteket és a jó tesztek tulajdonságait mutatjuk be.