5 gyakori hiba unit tesztek írásakor
Napjainkban az automatizált unit tesztelés a legtöbb fejlesztő mindennapjait képezi. Természetesen örvendetes, hogy a témában kevésbé jártas fejlesztők is nyitottak ezen metodológia felé, azonban van néhány visszatérő hiba, amivel a tapasztaltabb fejlesztők rendszeresen szembesülnek. Mai posztunkban ezekből szedtünk össze néhányat azért, hogy segítsünk nektek a tesztjeitek színvonalának javításában.
Unit tesztek egyszeri használatra történő írása
Ideális esetben a unit teszteket folyamatosan kellene újra és újra futtatnunk, ahogy a kód változik. Ez nem elsősorban a regressziók feltárása miatt fontos (azokat leginkább az integrációs tesztek tárják fel), azonban igen gyakori, hogy pár hónap elteltével egy adott metódus vagy osztály feladata, környezete változik, és a unit tesztek nincsenek többé szinkronban a valós követelményekkel. Ilyenkor ezek a tesztek törvényszerűen hibát fognak jelezni, ami összezavarhatja a teszteket futtató fejlesztőket. Ne feledjük: a unit tesztek elsődleges feladata az adott egység követelményeinek dokumentálása automatikusan ellenőrizhető módon, így kiemelt fontosságú, hogy a követelmények változását a tesztjeink is lekövessék.
Monolitikus tesztek
Gyakran látni azt a megoldást, amikor valaki egy metódushoz egyetlen tesztmetódust ír, és az összes vizsgálat (assert) ebben történik. Ez nem feltétlenül mindig ördögtől való, azonban meglehetősen rontja a tesztjeink minőségét, hiszen a legtöbb unit teszt keretrendszer megáll az első assert hamis kiértékelésekor, így a többi teszt eredményéről csak annak feloldása után informálja a fejlesztőt. Ilyenkor érdemes lehet a tesztet több különálló metódusra, tesztesetre szétbontani, lehetőleg metódusonként egy, vagy legfeljebb néhány (szorosan összefüggő) assert-el.
Tesztmetódusok nem megfelelő elnevezése, rossz dokumentáció
A tesztjeink nem egy vákuumban léteznek, hanem szoros részei a kódbázisnak. A rosszul (vagy sehogy sem) dokumentált tesztek nagy nehézséget okoznak egy, később a kóddal dolgozó másik fejlesztőnek (aki sokszor a fél évvel későbbi önmagunk...), és ismét csak rengeteg elpocsékolt időhoz vezethet. Adjunk leíró neveket a tesztmetódusainknak, amennyire csak lehet, vagy akár használjunk egy BDD-szerű módszert, ahol minden tesztet egy Given-When-Then formátumban írunk le. Ez kissé néha szájbarágósnak tűnhet, de jó szolgáltatot tehet a fentebb említett esetekben.
A unit tesztek csak a sikeres végrehajtási útvonalakat teszteli
Ez már kevésbé technikai kérdés, azonban gyakran előforduló hiba, hogy a unit tesztek az adott metódusnak csak egy vagy két optimális esetét tesztelik. Mindig gondoljuk végig, mik a negatív esetek, ne csak a "happy flow"-val számoljunk! A unit tesztek továbbá lehetőséget adnak szélsőséges esetek, edge casek egyszerű tesztelésére is, ami óriási hozzáadott értékkel bír, hiszen ezeket általában nehéz és/vagy időigényes az integrációs tesztek során előállítani (óriási adatmennyiségek, szélsőértékek, stb.).
A tesztelt metódus meg van hívva a teszt során, de semmilyen assertion nincs a direkt vagy indirekt kimenetére
Ez egy látszólag fura hiba, mégis relatíve gyakran látni. (Ennek az anti-patternnek egy variációja még ennél is rosszabb, amikor a metódus meg sincs hívva a tesztben...) Ügyeljünk arra, hogy a metódusunk kimenete, visszatérési értéke mindig validálva legyen a teszt során, akkor is, ha az esetleg csak egy egyszerű boolean érték. Persze felmerül a kérdés: mi a helyzet a void metódusokkal, amelyeknek nincs visszatérési értéke. Ez akár egy hosszabb cikket is megérne, azonban itt két dolog is lehetséges. Egyrészt előfordulhat, hogy a "kimenet" indirekt (pl. írás az adatbázisba), ilyenkor a mock/stub objektumainkat tudjuk ellenőrizni, de sokszor az is lehet, hogy a void metódus puszta léte egy rosszul tervezett osztályra mutat. Ne feledjük, a unit tesztek másik fontos feladata, hogy rámutasson tervezési hibákra, code smellekre, így mindig vegyük számításba ezt a lehetőséget is!
Ha hasznosnak találtad a cikket, oszdd meg ismerőseiddel, és természetesen az észrevételeiteket is várjuk a komment szekcióban!