Aktív fórum témákNavigáció |
Reddit: Egy kis teszt, egy kis kódolásÍrta: Dan Bunea Egy kis teszt, egy kis kódolás: gyakorlati bevezetés a TDD-be, vagyis a Tesztelésen Alapuló Programozásba
Előszó
A Tesztelésen Alapuló Programozás (angolul TDD) az egyik legelterjedtebb gyakorlat az Agilis közösségek körében. (az Agilis Programozás egy pár éves irányzat, több programozási módszertan is ide tartozik, például az Extreme Programming, de erről majd máskor - a ford.) Viszont szerintem nem sokan értik, hogy miről is szól pontosan, mert azt látom, hogy egy csomóan félreértik és rosszul használják a kifejezést. A legnagyobb félreértések a TDD-vel kapcsolatban Sokan, akik nem ismerik az Agilis programozási elveket, vagy kezdők benne, azt hiszik, hogy a TDD annyiból áll, hogy automatikus teszteket írsz a programod kipróbálására, vagy ami még rosszabb, hogy a TDD a program kipróbálására szolgál, és nem pedig a fejlesztésére. 1. A TDD a tesztelőknek szól Ez a kavarodás a TDD nevéből származik: Tesztelésen Alapuló Programozás, ami sok szoftverfejlesztőnek azt jelenti, hogy programot írunk a tesztelésre is, ami valójában a minőségellenőrző csapat dolga lenne. Amiatt, hogy a 'tesztelés' szó szerepel a nevében, sokan azt hiszik, hogy ez a lényege, tehát nem is kell a fejlesztőknek foglalkozni vele, mert majd a tesztelők elintézik. Ezt azok hiszik, akik csak a nevét ismerik, de semmit se tudnak róla (figyelsz, Shenpen?! - a ford.) Holott a cím elég egyértelmű: automatikus tesztek, amikre a programozás alapul. 2. Én TDD-t használok, mert a programomat automatizált módon tesztelem. Akik most ismerkednek az Agilis technikákkal, gyakran azt hiszik, hogy egy automatizált tesztsorozat, ami a kód minden részét leteszteli, egyet jelent a TDD-vel. Ez valójában nem is nagy tévedés, csak a dolog lényege pont az, hogy a teszteket a program megírása ELŐTT kell elkészíteni, és nem pedig utána. Ha a tesztprogram megírásakor nem változott meg a tesztelendő program, akkor ez nem TDD, hanem csak automatizált tesztelés, ami persze szintén nem rossz dolog. Az automatizált tesztek megléte legalábbis arra feljogosít, hogy részlegesen TDD-nek nevezhesd a módszert, még akkor is, ha a teszt később készült el, mint a program maga, mivel magasabb szinten, vagy pontosabban projekt-szinten, az a TDD lényege, hogy kiderüljön, ha valami elromlott attól, amit egy fejlesztő csinált, mert esetleg olyan koncepcionális vagy gyakorlati változásokat von a változtatás magával, amik a program alapjainak megváltoztatását igénylik. Az elmélet A Tesztelésen Alapuló Programozás egy szoftverfejlesztési technika, ami szoftverfejlesztőknek, és nem pedig szoftvertesztelőknek készült, és arra alapszik, hogy először automatikus tesztet kell csinálni egy adott dologra, és utána annak megfelelően írni meg magát a kódot. A kód elsőre nem, de végül átmegy a teszten, ami azt jelenti, hogy azért lett a kód olyan, amilyen, hogy a teszten átmenjen. Ezt a technikát elég sokan leírták már, úgyhogy nem is akarok sok szót vesztegetni a bemutatására. Nevezik amúgy piros-zöld faktornak is. Egy kis teszt, egy kis kódolás, nem jó, megint egy kis kódolás, és máris jó. Ezekből a lépésekből áll alapvetően az egész. Tehát ez teljesen programozási technika, csak kicsit más. Összefoglalva a lépéseket: 1. Teszt: írj meg egy tesztet. Csak egy dolgot tesztelj, sose többet. Ez a lehető legegyszerűbb módja a lépések leírásának. A teljes lista ennél hosszabb, mert az 1. lépés jelentős részben gondolkodásból áll, először ki kell találnod, hogy mit is akarsz, aztán azt, hogy hogyan lehet azt a lehető legegyszerűbben letesztelni, és aztán lehet továbblépni a következő lépésekre. Elég sokszor vissza is kell ugrani, hogy az eredmény jó legyen. Ez egy iteratív eljárás, aminek az a lényege, hogy először tesztelsz egy kicsit, aztán kódolsz egy kicsit, amíg a teszten át nem megy, aztán ezt ismételgeted, amíg mindennel kész nem vagy. Gyakorlat Tegyük fel, hogy a megrendelő kért egy rendelési rendszert, ami árengedményt ad bizonyos összegű megrendelés esetén az egész rendelésre. Az Extreme Programming szerint ez egy 'felhasználói sztori' leprogramozása lenne.
De még nincs Megrendeles osztályom. A második lépésben viszont el kell érnem, hogy a kód leforduljon, de a teszt elbukjon. Úgyhogy ezt írom:
Most már lefordul, úgyhogy lássuk, mi lesz belőle: Eddig könnyű volt, most a harmadik lépésben átírom úgy a kódot, hogy átmenjen a teszten:
Azáltal, hogy mindig nullát adok vissza, a kód használhatatlan, de átmegy a teszten. Viszont ez csak egy példa, ami remekül megvilágítja azt, hogy a lényeg az, hogy a kód átmenjen a teszten, és ha az ember folyamatosan erre koncentrál, akkor ez fogja az egész fejlesztést meghatározni, tehát sosem szaladunk át semmin.
Király, most már átmegy a teszten, nézzük, kell-e átdolgozni valamit. Mivel a kód most még túl egyszerű ehhez, ezért ezzel nem kell foglalkozni, és az első iterációval meg is vagyunk. Most vissza az első lépéshez, adjunk hozzá megrendelés-sorokat.
Csináljuk meg addig, hogy leforduljon, tehát írjuk meg a MegrendelesSor osztályt és a HozzaadSor függvényt:
public class Megrendeles Lássuk, elhasal-e:
Akkor most az jön, hogy csináljuk meg, hogy átmenjen a teszten.
public decimal Osszeg És a MegrendelesSor:
Nahát, már másodjára sikerül tíz perc alatt :) Lássuk, van-e átdolgoznivaló. Maga a kód rendben van, de a teszttel kezdhetnénk valamit, mert kétszer inicializálja a Megrendeles-t. Át kéne ezt rakni valami Kezdoertek nevű eljárásba, mert az úgyis lefut minden más függvény előtt, meg a MegrendelesSor-t is elég hasonlóan gyártjuk, arra is írjunk függvényt.
Megrendeles megrendeles = null; [Kezdoertek] Na lássuk, átmegy-e:
Átmegy, úgyhogy a kód jónak látszik, és megvagyunk a második iterációval is, többé-kevésbé letesztelve. Akkor most adjuk hozzá a kedvezményes részt, ugyanígy az első lépéstől:
Miután mindent megírtunk úgy, hogy a teszt elbukjon, aztán úgy is, hogy átmenjen, amit most itt nem részletezek tovább, azt fogjuk tapasztalni, hogy a teszt nem hajlandó átmenni.
Van egy bugunk a tesztben. Utánanézve kiderül, hogy a harmadik megrendeléssort elfelejtettük hozzáadni, úgyhogy gyorsan adjuk hozzá, és futtassuk le a tesztet. Ebből kiderül, hogy ez a tesztelősdi segít kijavítani a kód hibáit is, meg a tesztprogram hibáit is:
Nos, úgy tűnik, sikerült olyan tesztet csinálnunk, amik segítettek a kód megírásában. Ha ezeket a teszteket hozzátesszük a projekt közös tesztjéhez, és rendszeresen futtatjuk őket, akkor elég jól meg tudjuk majd mondani, hogy mi nem jó a kódban és hol. Forrás:
|
Friss blogbejegyzésekBelépésVörös RébékAz első album legjobb számai: Kicsi lovam Érdekes oldalakHírek, érdekességekOnline felhasználók
Jelenleg 0 felhasználó és 3 vendég van a webhelyen.
|
Friss hozzászólások
3 év 10 hét
3 év 11 hét
3 év 16 hét
3 év 16 hét
3 év 35 hét
3 év 35 hét
3 év 35 hét
3 év 35 hét
3 év 40 hét
3 év 40 hét