Skip to content

Automatizált integrációs tesztek

Miért?
Az integrációs tesztek gondoskodnak arról, hogy a kód azt tegye, amit tennie kell. Ezt a rendszeres tevékenységet nem automatizálni időpocsékolás volna.

A legalapvetőbb feltételét a kód megváltoztatásának már a piros fokozaton lefektettük a verziókövető rendszer használatával. Aggodalom nélkül változtathatunk a kódon, egész fájlokat vagy könyvárakat törölhetünk le, a verziókövető rendszerből mindezt újra ki lehet venni.Amikor csak változtatásokat eszközölünk a kódon, mindig biztosnak kell lennünk abban, hogy semmit sem rontottunk el. És erre a biztonságra csak akkor tehetünk szert, ha a változtatások után teszteljük, hogy az alkalmazás úgy viselkedik-e, mint előtte. Ezeket a teszteket minden változtatás után kézzel végrehajtani nem volna megoldható, automatizálnunk kell azt. A szoftverfejlesztés egyik nagy baja a félelem attól, hogy valami fölött elsiklik a figyelmünk, hogy egy részletre nem terjed ki a figyelmünk, és ezáltal hibát okozunk olyan kódban, ami előzőleg működött. És ennél még az sem játszik szerepet, hogy a változtatások ahhoz vezetnek-e hogy javítjuk a kódot (refaktorálunk) vagy új követelményeknek megfelelően bővítettük azt. Addig amíg nem vagyunk biztosak benne, hogy a minden úgy működik, ahogyan előtte, addig marad a félelem. Ez ahhoz vezet, hogy kétség esetén a kódot úgy hagyjuk, ahogyan van, hiszen az működik. A szükséges refaktorálásokat elmulasztják a hibázás miatti félelemből.

Ahhoz, hogy a már futó projektekben (un. Brownfield projetekeben, ellentétben a Greenfield „zöldmezős”) meg tudjuk teremteni a biztonsági hálót, olyan eljárásokra van szükség, amiket a meglévő kódra lehet alkalmazni. Ehhez alkalmasak az automatizált integrációs tesztek. Vagy a felhasználói felületen kezdjük ezt el, és végig tesztelünk az alkalmazást összes rétegen keresztül, vagy lejjebb kezdjük el. Mindkét esetben több funkcionális egység összjátékát teszteljük.

Tehát mielőtt változtatásokat eszközölnénk a kódon, az érintett kódterületek lefedésére integrációs teszteket hozunk létre. Persze ebben a folyamatban használhatunk olyan eszközöket, mint a WatiN, UI Automation stb. Kívánatosak volnának persze a unit tesztek is, amelyek az egyes funkcionális egységeket elszigetelten tesztelik. Ehhez azonban a kódnak bizonyos feltételeknek kell megfelelnie, melyek vélhetően nem mindig adottak: a kódnak tekintettel kell lennie a Single Responsibility-elvre. Ellenkező esetben az egyes funkcionális egységek (komponensek, osztályok, eljárások) között olyan nagyok lesznek a függőségek, hogy nem lehet őket elszigetelten tesztelni. A távlati cél természetesen egy olyan kódbázis, amelyen lehetségesek a unit tesztek. Sőt, a jövőben a teszteket az implementálás előtt fogjuk létrehozni (Test first). De ahhoz, hogy a refaktorálással odáig el tudjunk jutni, először integrációs tesztekre van szükség, hogy biztosra mehessünk, az alkalmazás még mindig úgy viselkedik, mint a refaktorálás előtt.

Lásd az Eszközök alatt.

Published inPraktikák