Skip to content
Aug 31 10

F.I.R.S.T. szabály

by firith

A jó tesztek az alábbi öt jellemzővel rendelkeznek:

Fast: A teszteknek gyorsan kell lefutniuk, mert lassú teszteket nem szívesen futtatunk gyakran, így  nem találjuk meg elég hamar a hibákat ahhoz, hogy könnyen javíthassuk őket. Emiatt nem merjük a kódot refoctorizálni, tisztítani, ami a kód minőségének romlásához vezet.

Independent: A tesztek nem támaszkodhatnak egymásra, nem élhetünk feltételezésekkel a következő teszt számára. Szabadon kiválasztott vizsgálatok önállóan is futtathatóaknak kell lenniük, bármilyen sorrendben. Az egymásra támaszkodó tesztek esetén, ha az első kudarcot vall, magával rántja a többit is, ami megnehezíti a hiba okának megkeresését és elrejtheti a sorban következő hibákat.

Repeatable: A teszteknek bármely környezetben megismételhetőnek kell lennie: képesnek kell lenniük a futásra mind az éles környezetben, mind a fejlesztői gépünkön, ahogy a laptopunkon is, miközben hálózat és internet nélkül utazunk.

Self-validation: A teszteknek logikai eredményt kell adniuk: siker vagy kudarc. Nem szabad, hogy naplófájlt kelljen végigolvasnunk, szöveges fájlokat kelljen összehasonlítanunk ahhoz, hogy megmondhassuk a teszt sikerrel járt-e. Az ilyen tesztek nem egyértelműek így a kudarc viszonylagossá válik és hosszas értékelést vonhat maga után.

Timely: A teszteket a megfelelő időben kell megírni, közvetlenül az előtt az üzemi kód előtt amelynek teljesíteni kell őket. Ha a teszteket az üzemi kód elkészítése után írjuk, akkor előfordulhat hogy a kódot nehezen lehet majd ellenőrizni és esetleg nem is úgy terveztük meg a kódot, hogy tesztelhető legyen.

forrás: Robert C. Martin: Clean Code, A Handbook of Agile Software Craftmanship

Aug 30 10

PHP Unit tesztek

by firith

Programozás közben a legtöbb időt a programhibák felkutatása teszi ki, míg maga a hiba kijavítása időnként nem vesz el egy-két percnél többet. Ráadásul nem tudhatjuk, hogy a javítás hatására nem jelenik meg máshol egy újabb hiba, amit csak sokkal később veszünk észre, így megtalálása nagy fejtörést okozhat.

A jó tesztek önmagukat értékelik ki, nem igényelnek emberi beavatkozást. Ez fontos, mert így gyorsabb és kényelmesebb használni ráadásul egy hosszabb tesztcsomag felügyelet nélkül is lefuthat, amíg elmegyünk ebédelni, tárgyalásra.

PHP nyelvhez három tesztelő keretrendszert is használhatunk:

  • PHPUnit: talán a legfejlettebb eszköz a háromból, képes tesztgenerálásra, megépítve a teszt vázát, hogy nekünk már csak a tényleges vizsgálatot kelljen megírnunk. NetBeans IDE által támogatott.
  • SimpleTest: egyszerű és könnyen használható, a JUnit java tesztelő rendszer ihlette. Tartalmaz unit és web teszteket is. Eclipse IDE által támogatott
  • Lime: a symfony framwork beépített unit és functional (web) tesztkészlete

Teszteket írni még az üzleti kód előtt érdemes, majd folyamatosan bővíteni kell a program fejlesztése közben. Az extrém programozás egyik legfontosabb érve a gyakori tesztelés. Mivel céljuk a leggyorsabb szoftverfejleszés automatikus tesztekkel segítik munkájukat.

Másik fontos alkalmazási terület a refactoring. Meg kell győződnünk arról, hogy az újratervezés nem rontotta el a már működő kódunkat. Az apró módosítások közben sokszor futtatjuk a teszteket, ennek vizsgálatára.

A következő cikkemben egy példát mutatok be a teszt vezérelt fejlesztésről.

Aug 18 10

PHP refactoring eszközök hiánya

by firith

Tanácsadói munkám során nem győzöm hangsúlyozni a tiszta és jól olvasható kód előnyeit. Fejlesztők között elterjedt mondás, hogy egy kódot többször olvasunk, mint ahányszor írunk. Ez azért is igaz, mert a kód írása közben vissza-visszaolvassuk az előző sorokat, a meghívott metódus törzsét, az osztályt amit használni akarunk.

A tiszta kód másik előnye, hogy könnyen módosítható, új szolgáltatás hozzáadása nem okoz problémát. Soha ne felejtsük el, hogy mások is dolgoznak a kódunkon, könnyítsük meg a munkáját, hogy ne kelljen elvesznie a részletekbe, ha egy átfogó képet akar kapni a szoftver működéséről. Ha úgy gondoljuk, ezzel a kóddal csak mi dolgozunk, akkor is van egy másik személy akinek segítenünk kell: későbbi önmagunk, amikor pár hónap, év múlva módosítanunk kell a programot.

Szerencsére erről a témáról rengeteg jó könyv jelent meg, még magyarul is:

Ezek – ha szabad így fogalmaznom – kötelező olvasmányok minden magára adó programozó számára, akiknek az előállított kód minősége személyes kérdés, amiben kifejezi tapasztalatát, tudását és stílusát.

Sajnos PHP nyelvhez nem készültek jó újratervező eszközök, mint más nem script nyelvekhez. A fejlesztőkörnyezetek nagyon kevés dologban segítenek, emiatt mindent kézzel kell csinálnunk, nem támogatnak automatikus eszközökkel. Mivel a PHP nem típusos nyelv, és Objektumorientált módszertant sem kielégítően követi, nehéz a kód automatikus felderítése.