Skip to content

Kategória: Praktikák

Automatizált unit tesztek

Miért?
Csak az automatizált teszteket hajtják végre igazán konzekvensen. Minél pontszerűbben tesztelik a kódot, annál jobb.

A narancs fokozaton bevezettük az integrációs teszteket, most a unit teszteken a sor. Az integrációs tesztekkel szemben a unit teszteknél egyetlen funkcionális rész (leginkább osztályok vagy eljárások és komponensek) kerül elszigetelt tesztelésre. Ehhez az szükséges, hogy megszabadítsuk ezeket a funkcionális egységeket a függőségeiktől. Amennyiben a unit tesztekkel utólag kell egy meglévő kódot kibővíteni, akkor gyakran szükségesek refaktorálási műveletek. Az integrációs tesztek által meg van az a biztonságunk, hogy közben nem fogunk hibázni.

Az automatizált tesztek kétfajta hasznot hoznak:

  • Időt takarítanak meg
  • Elveszik a félelmet

Minél erősebben változik egy kódbázis, annál jobban lehet érezni az időmegtakarítást. Mert ahol kód változik, ott újra és újra tesztelni kell a régit és az újat (regressziós tesztek). Ilyenkor az automatizálás időt takarít meg. És minél komplexebb a kód, annál jobban csökkenti a félelmet. Mert, ha komplex kódot kell megváltoztatni – hogy funkcionalitást adjunk hozzá, optimalizáljuk, vagy hogy csak simán javítsuk – akkor fennáll annak a veszélye, hogy akaratlanul hibát okozunk. A kislépésű automatizált tesztek azonban felfedik ezeket, így hát nincs okunk attól félni, hogy elrontunk valamit.

Lásd még az eszközök alatt.

Mockup-ok

Miért?
Álobjektumok (mockup) nélkül nincsenek egyszerűen kontrollálható tesztek.

Általában a komponensek további komponenseket használnak. Amennyiben az ember egy komponenst elszigetelten akar teszteleni, le kell választani a függőségeit. Ekkor minket csak és kizárólag a tesztelendő komponens funkcionalitása érdekel (System Under Test (SUT)). És az érdekel minket, hogy a komponens hogyan lép kölcsönhatásba másokkal.

Az elszigetelésnél úgynevezett mockup-okat használunk. Ezeket használjuk az igazi komponensek helyett. Így a System Under Test a tesztek alatt valódi komponensek helyett jól kontrollálható álobjektumokkal lép kölcsönhatásba.

A szakirodalom más neveket is használ az álobjektumokra, mint stub, dummy vagy fake, melyek részben a mockup szinonímái, de nagyon is más működési módokat takarnak. Mielőtt az ember egy mock framework-öt, mint pl. a Rhino Mockst használna, azelőtt egy mockup-ot „kézzel” kellene implementálni. Ez segít a mechnizmus megértésében.

Lásd még az eszközök alatt.

Kód lefedettség (code coverage) vizsgálat

Miért?
Csak olyan teszteknek higgy, melyekről tudod, hogy valóban lefedik a tesztelendő területet.

A unit teszteknek lehetőség szerint a kódunk minden útvonalát le kellene fedniük. Csak akkor nyerjük el annak bizalmát, hogy a kód helyesen dolgozik. Hogy megtudjuk, mely kódrészeket nem fedtünk még le a tesztekkel, ahhoz a kód lefedettség (code coverage) vizsgálathoz folyamodunk. Ez arra szolgál, hogy felfedezzünk a kódban olyan területeket, melyek nem hajtódnak végre az automatizált tesztjeink során.A unit teszteknek tulajdonképpen a tesztelendő kód 100%-át le kellene fedniük. Ez ugyan nem jelenti automatikusan, hogy elegendő teszt létezik, de a 100%-nál alacsonyabb kód lefedettség arra utal, hogy vannak olyan zugai a kódnak, amely helyességéről nem tudunk nyilatkozni. Ezért érdemes mindig 100%-os kódlefedettségre törekedni.

A gyakorlatban azonban azt láthatjuk, hogy a 100%-os kódlefedettség nem mindig érhető el vállalható ráfordítással. Ahogyan az életben is, az utolsó 2, 3, 4 százalékra fordított fáradság aránytalanul megnőhet. Ezért a lefedettség pontos elemzése után elfogadható, ha kevesebb mint 100%-kal megelégszünk.

90% alatt a lefedettség azonban annyira lyukacsos, hogy nem tekinthető professzionálisnak. Aki tehát elkezdi használni az automatizált teszteket, annak egyidejűleg a kódlefedettséget is kellene mérnie. Különben nem lehet nyilatkozni a tesztek minőségéről.

A kódlefedettség mérésére két mutató szolgál, melyek C0 és C1 néven ismertek. A C0 mutató az utasításlefedettséget méri, míg a C1 mutató az elágazáslefedettséget.

C0 = (a tesztelt utasítások száma / az összes utasítás száma) * 100%
C1 = (a tesztelt döntések ill. ágak száma / az összes döntés ill. ág száma) * 100%

A C1 egy erősebb mutató, hiszen 100%-os döntés- ill. áglefedettség 100%-os utasításlefedettséget implikál. Ennek a megfordítása nem igaz.

Az utasításlefedettség-teszt és az elágazáslefedettség-teszt egy vezérlésfolyam-gráf alapján dolgozik, lásd http://hu.wikipedia.org/wiki/Vez%C3%A9rl%C3%A9sfolyam-gr%C3%A1f, míg a döntéslefedettség-teszt közvetlenül a forráskódon alapul. Az utasításlefedettség-tesztek és elágazáslefedettség-tesztek teszteljárása nagyon jól van leírva a http://en.wikipedia.org/wiki/Code_coverage oldalon és az angol párján.

Lásd még az eszközök alatt.

Részvétel szakmai rendezvényeken

Miért?
Legjobban másoktól és társaságban lehet tanulni.

Ahhoz hogy ne csak „a saját levünkben főjünk” fontos, hogy rendszeresen cseréljünk tapasztalatot, vitatkozzunk más szoftverfejlesztőkkel. És hogy mindeközben kitekintésünk legyen a saját kis világunkból, ahhoz ezeknek a találkozásoknak a saját team-ünkön és a napi rutinon kívül kell megtörténniük. Alkalmasak erre konferenciák, előadások, meetupok.Itt a tapasztalatcsere áll előtérben. Ez fontos. De minél inkább egyazon csoporton belül vagyunk, minél jobban ismeri az ember a beszélgetőpartnereit, annál inkább kiegyenlítődnek a vélemények. Éppen ezért fontos az, hogy újra és újra kitekintsünk ebből a kis világból is. Új gondolatokat tehát inkább a nagyobb fejlesztői konferenciák fognak hozni.

Az eszmecserére tehát a Clean Code fejlesztőnek három szintet kellene szem előtt tartania: a saját fejlesztőcsapatát, a kisebb előadásokat, meetup-okat, és a nagyobb konferenciákat. Mindegyik szintnek meg van a saját ritmusa: naponta, havonta, évente.

Linkek:

Komplex refaktorálások

Miért?
Nem lehetséges a kódot egyből a legutolsó formájában megírni.

Már a piros fokozaton bevezettük az egyszerű refaktorálást. De az átnevezés és az eljárás kiemelése nem elegendők a kód javításához – gyakran nagyobb beavatkozásokra van szükség. Van értelme az egyszerű és komplex refaktorálások felosztásának, mert a komplex refaktorálásokat csak már létező automatizált tesztekkel lehet hatékonyan és kockázatmentesen végrehajtani. Tesztek nélkül a refaktorálás után nem lehetne tudni, hogy a kód helyes-e még mindig.

Lásd még az eszközök alatt.