A Unit tesztek jelentősége a fejlesztés során

Az observer mintára írt példámban, ahol több osztályt is felhasználtam vétettem egy hibát. Ez a hiba kattintásos tesztelési módszerrel vagy a kőbaltás var_dump módszerrel esetleg soha, vagy nagyon hosszú idő múlva derült volna ki. Számomra ekkor világosodott meg a Unit testek jelentősége.

Miről is van szó pontosan?

Fejlesztéseink során számalanszor szükség van módosításra, új igények megvalósítására. Ehhez a már meglévő kódhoz kell hozzányúlunk, a meglévő funkciókat ki kell egészítenünk vagy újakat kell létrehoznunk. Osztályokat tervezünk újra, kódrészleteket emelünk ki, vagy esetleg csak újakat építünk be. Képzeljük el, hogy ezt nem csak egymagunk végezzük, hanem egy csapatban dolgozunk és mások is dolgoznak azon az osztályon, amelyen mi már változtattunk az igényeknek megfelelően. Az eredmény egy dinamikusan változó, jó esetben egy egyre jobban működő, hatékonyabb és funkciókban gazdagabb kód lesz, ami tükrözi az elvárt követelményeket. A folyamatos változtatás és fejlesztés során ellenőriznünk és ügyelnünk, kell, hogy a már létező és jó működésben ne okozzunk zavart. Ezt a jól tervezett, szervezett és ellenőrzött kóddal tudjuk elérni.

Tételezzük fel, hogy van egy logikai egységünk, amit a változtatás után is szeretnénk, hogy jól működjön, mondjuk egy osztályunk. Elvégzem a módosításokat, majd a hagyományos módon ellenőrzöm, hogy vajon jól működik-e, majd a változtatást elmentem. Tételezzük fel, hogy valaki megint változtat rajta és megint ellenőrzi, hogy jól működik-e. Az ellenőrzések vagyis az osztályok, mint logikai egységek tesztelésre használhatunk előre megírt, automatizált teszteket is, amelyeket egyszer kell megírni, majd utána csak futtatni kell. Ezáltal egyrész időt nyerhetünk, másrészt az automatizálás révén biztosak lehetünk benne, ha jól írták, meg, akkor hibátlan lesz a végeredmény. A lényeg, hogy még fejlesztési időben kiderüljön minden rendellenes működés. Az én példám azt is bizonyította, hogy olyan hibát vettem észre, ami egyébként első ránézésre nem derült volna ki.

A teszteléshez felhasznált eszköz, a PHPUnit.
A keretrendszer gyűjtőnévként, csak xUnit néven ismert. Kent Beck találta ki, aki először a Smalltalk nyelvre készítete el, majd később JUnit néven a Java nyelvre adaptálták, ezután pedig számalan más nyelvre is. Sebastian Bergmannak köszönhetően PHP nyelvre is, PHPUnit néven.
Példa:
Az observer mintához kapcsolódóan először érdemes tisztázni, hogy mit is várunk a konkrét teszteléstől?
  1. A login során a beléptetéseknek megfelelően veszik fel az állapotokat
  2. Az egyes állapotokról értesülnek a megfigyelő objektumok
A teszt futtatásának előfeltétele, a használt keretrendszer, a szükséges osztályok és a kialakított táblák megléte a példában leírtaknak megfelelően. Vagyis létezik egy teszt user, akinek ismerjük a jelszavát. A következő teszteseteket vettem figyelembe:
  • A jelszó és felhasználói név jó, az utolsó belépés dátuma kisebb, mint 30 nap a belépés sikerül, az állapota: Success (0)
  • A jelszó rossz, a felhasználói név jó, a belépés nem sikerül, az állapot: Bad password (2)
  • A felhasználói név rossz, a jelszó jó, a belépés nem sikerül, az állapot: Bad username (3)
  • A felhasználói név jó, a jelszó rossz formátumú, a belépés nem sikerül az állapot: Login too much (6)
  • A felhasználói név jó, a jelszó jó, a belépés nem sikerül, az állapot: Login banned (5)
  • A felhasználói név jó, a jelszó jó, az utolsó belépés dátuma nagyobb, mint 30 nap, belépés nem, állapot: Login expired (4)
A PHPUnit futtatása:
A Pear csomagok részeként a szokásos módon telepíthetjük, majd elérhető a keretrendszer, amely megkönnyíti a tesztelés folyamatát. Minden teszt egy legfelső PHPUnit teszt osztályból származik. Készítetem egy teszt osztályt, amely a meglévő osztályból származik, amelyet tesztelni szeretnék. Erre azért volt szükség, mert olyan metódusokat helyeztem el benne, amelyekre csak a tesztelés során van szükségem. Megírtam a teszteseteket és futtattam.
Eredmény:
Az elkészített osztályomban egy logikai hiba történt, amit a tesztesetek írása, illetve a futtatás során vettem észre. A LOGIN_TOO_MUCH állapot soha nem fog bekövetkezni, mert előtte kitiltom a felhasználót. Tehát ez egy felesleges be nem következett állapot. Jóllehet az osztály jól működik, mégis tartalmazott egy hibát. Most, hogy rendelkezem a tesztosztállyal, a módosításaim során bármikor könnyedén ellenőrizni tudom, hogy az alapfunkciókban történt-e változás, így sokkal hamarabb és gyorsabban ki tudom szűrni az esetlegesen bekövetkező hibákat.
Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter


A bejegyzés kategóriája:Programozás and tagged . Vedd fel a kedvencek közé: link. Szólj hozzá vagy hagyj egy trackback-et:Trackback URL.

Szólj hozzá

Hozzászólás küldéséhez Be kell jelentkezni