Ma, ahogyan ígértem arról lesz szó, hogyan tudjuk tesztelni az elkészített modulunkat.
A Drupal hetes egyik legnagyobb újításai közé tartozik az, hogy a minőség biztosítása érdekében bevezették az automata tesztelést. Mielőtt rátérnénk arra, hogy ez miért jó és hogyan használható, előtte tegyünk egy kis kitérőt a programozott tesztelés felé.
Az elmúlt hónapokban Marhefka István aka info@ és Zsoldos Péter alias zsepi kalauzolásával merültem el a Test Driven Development világában. Mindketten igen komoly nagyvállalati tapasztalattal rendelkeznek e téren. Egyikük a Javas világot ismeri jobban, míg másikuk a .Net fejlesztőeszközök használatában jártas. Azonban, amit tanultam tőlük, az jóval több mint eszközök puszta ismerte.
A módszer röviden annyi, hogy mielőtt nekiállnánk a kód írásának, a kód automata tesztelését lehetővé tevő teszteseteket írjuk meg. Egy új funkció bevezetése a következő lépésekből kell, hogy álljon:
- Adj hozzá egy tesztet
- Futtasd a teszteket és figyelj arra, hogy az új teszted elbukjon
- Írd meg a kódod
- Futtasd a teszteket és figyeld, hogy mindegyik teszt sikeres legyen
- Refaktoráld a kódodat a tesztek segítségével
Első hallásra a világ legnagyobb hülyeségének tűnik, hogy az ember először tök feleslegesnek látszó kódsorok gyártásával foglalkozzon és csak utána lásson neki a tényleges hasznot hajtó kódsorok bepötyögésének. Amennyiben az ember ráveszi magát, hogy egyedül kipróbálja ezt a metodikát, biztosan elmegy tőle a kedve. Elmegy, hisz éppen egy tanulási folyamat elején vagyunk, így az egy-két hónapos gyakorlás utáni egy perces munkákkal az elején, akár egy napot is elbíbelődhetünk.
Amennyiben belevágunk egy ilyen kalandba nem baj, ha megfelelő motiváltsággal, kitartással és egy tapasztalt segítőtárssal vágunk bele. Nekem ez utóbbiból szerencsére kettő is akadt.
Nézzük milyen előnyökkel jár, ha ezt a metodikát követjük.
Az első nyereség az abból adódik, hogy mint mindig, a legelején meg kell terveznünk azt, hogy mit fogunk elkészíteni. Ennek a tervnek a végeredménye tud lenni egy olyan kis program, ami leírja azt, hogy mi az elvárt működése a programunknak. Gondoljunk bele. Már egy egyszerű függvénynél is meg szoktuk mondani, hogy milyen bemeneti paraméterekre milyen kimenetet várunk. Miért ne tennénk ezt úgy, hogy azt később is fel tudjuk használni? Később, amikor már nem lesz kedvünk minden egyes javításkor az összes lehetséges esetet végigpróbálni. Ekkor rettentő jól fog jönni, hogy ezt egy gépre, egy automatára bízhatjuk.
Ha a fenti elképzelés nem is szimpatikus, akkor is valahogyan ki kell próbálnunk az általunk elkészített kódot. Gondoljunk bele, ilyet mi is csinálunk. Folyamatosan készítünk apróbb tesztkódokat, amiket azután kitörlünk. Miért ne őrizhetnénk meg ezeket? Miért kéne kidobálnunk ezt a munkánkat?
Tudom, hogy hihetetlennek hangzik, de amennyiben elég jól ismerünk egy teszt keretrendszert, vagyis, megfelelő gyakorlatunk van a használatában, a plusz munka költsége gyakorlatilag nulla.
Persze, ha valaki erre azt mondja, hogy ez nem igaz, annak igazat kell adnom. Nem nulla, annál jóval kevesebb. Kevesebb, hisz ebben a pillanatban a rövid távú nyereség mellett hosszú távú nyereségeink is lesznek. Ki gondolná ugyanis, hogy egy jól kitesztelt helyen a kódban még egy hiba felbukkanhatna? Senki. Ha jobban belegondolunk, mi is tudunk ilyen eseteket mondani, ráadásul valószínűleg arra is emlékszünk, hogy ezeknek a hibáknak a megtalálására mennyivel több időt kellett anno fordítanunk. Ezeket a régebben kidobált időket is megnyerhetjük.
Amikor azt mondom refaktor, lehet többek ereiben meghűl a vér. Azonban ha azt is közlöm, hogy én refaktor alatt arra gondolok, hogy átírom a kódomat pusztán azért, hogy szebb és tisztább legyen, már többek nemtetszését is kivívhatom. Kivívhatom, hisz azért dolgozzak, hogy se gyorsabb, se jobb ne legyen a kódom, csak más? Puszta programozói kivagyiságból? Csak azért, hogy élvezettel nyúlhassak hozzá és ne kelljen fintorognom az egy két hónappal ezelőtt írt szörnyszülöttem miatt? Miért nem írtam már meg az elején jól? Azért, mert én lennék a legszomorúbb, ha két hét múlva ugyanaz a programozó lennék. Ugyanazokkal a módszerekkel gyártanám az ugyanolyan kódot. Ekkor nem programozó lennék, hanem kisipari kódsegédmunkás.
Természetesen nem beszéltünk arról, hogy mi van, ha csapatban dolgozunk. Akkor ezek az igények hatványozottan jelentkeznek, hisz nehéz úgy közösen dolgozni, hogy mindenki csak a saját gondolatmenetének megfelelő kódot gyárt.
Egy ilyen refaktor hosszú távon nagy nyereséggel kecsegtet, de automata tesztek nélkül elképzelhetetlen, hogy ennek a munkának az ember nekilásson. Ezért is jó a menet közbeni tesztkódokat megőrizni, hisz nem kerül semmibe se (a kezdeti tanulási időszakon kívül természetesen), csak nyereségünk lesz belőle.
A harmadik lehetőség az, hogy egy hiba kijavítása után írunk egy rövidke kis tesztet, mely biztosítja azt, hogy a hiba megléte esetén jajveszékeljen a rendszerünk, míg a javítás utá szép csendben lefussanak a tesztek. Ez utóbbit használják elsősorban a Drupal hetes fejlesztése során.
Ezzel a módszerrel el lehet kerülni azt, hogy egy már, a rendszerbe bekerült hibajavítás onnan, valamilyen véletlen folytán kikerüljön, valamint csökkenteni lehet annak az esélyét, hogy egy hibajavítás újabb hibák garmadát generálja.
Amint láttuk, lehet a fejlesztés előtt, a fejlesztés alatt és a fejlesztés végén is használni ezt a módszert. Tapasztalt barátaim szerint azonban a fejlesztés utánra már semmi esetre sem érdemes hagyni, mert akkor nagyon nagy valószínűséggel csak egy frusztráló, kellemetlen hiányérzetünk lesz csak egy el nem végzett feladat után. Nem beszélve arról, hogy olyankor már tényleg csak nyűg lesz ez a feladat és semmi előnyét nem fogjuk élvezni.
Nézzünk meg, hogy a tegnapi kis próba modulomban én hogyan használtam a fent leírtakat.
tovább
