Kódlefedettség-mérés

A jtechlog-ban volt egy írás a code coverage-ről ahova be is böfögtem egy kommentet. Na most én is írok róla.

Az Emma is egy ilyen kódlefedettségmérő eszköz, ami mindenféle riportokat tud csinálni XML és HTML formában. De én nem szeretek build scriptből és command promptból bűvészkedni ha kódlefedettséget akarok nézegetni, szóval beérem az Eclipse plugin változatával, az EclEmma-val. Europa környezetben használtam eddig és most felraktam a Gánymedvére is (by czimi). Azon is megy szépen.

Tud package, osztály, metódus, blokk és utasítás lefedettséget. Szépen fában jeleníti meg és lehet nyitogatni, odaugrik a kódra ha klikkelek, valamint kiszínezi a kódot, szóval meg lehet nézni hogy mi hajtódott végre teljes egészében és mi részlegesen végül mi az ami kimaradt a szórásból. El lehet tenni régi riportokat, előszedni de ezt sosem használtam. Be lehet jelölgetni a kapcsolt jar-okat, hogy azoknak is mérje a lefedettségét. Az EclEmma-s honlapon van screenshot, több infó.

Node mire jó ez?

Legalapvetőbb célja az lehet, hogy a unit tesztek a kód hány százalékát hajtják meg. Első közelítésben ez egy szám ami nem sokat mond. Kényelmes test driven fejlesztésnél nálam 70-80 százalék jön ki. Fel lehet tornázni 95, sőt 100%-ra is, de ez már néha igen sok melóval jár, főleg a szoftver határai közelében (I/O). Mindenféle mock-okat kell csinálni, le kell tesztelni mi a helyzet, ha egy stream close() metódusa elszáll IOException-nel, le kell tesztelni az UnsupportedEncodingException-t akkor is ha statikusan megadtuk az encoding-ot. (Checked exception, de minek.)

Akkor kezd izgalmassá válni a dolog, ha megnézzük hogy miért nem 100%, miért csak 70, elkezdjük lenyitogatni a fát, látjuk hogy egyes metódusoknak 0% a lefedettségük. Ilyenkor érdemes megnézni (CTRL+ALT+H) a metódus fordított hívási fáját, azaz hogy használja-e egyáltalán valaki. Nem használja, akkor meg miért van ott? Ha szükséges lesz az a metódus a jövőben akkor érdemes rá valami tesztesetet írni, hogy legyen valami contract-ja, ha nem akkor pedig ki lehet törölni. Ezzel is javul a lefedettség.

Más esetekben a metódusokon belül nem hajtódnak végre bizonyos ágak. Igazi TDD-nél ennek nem nagyon szabadna előfordulnia, de ha mégis akkor pótolni kell a hiányosságot mihamarabb.

Ad hoc tesztelésről feltornázni a teszt lefedettséget -próbáltam- egy rendkívül unalmas és szélmalomharcnak tűnő feladat. Az eredmény sem lesz olyan jó, mintha már az elejétől folyamatosan készülnének a tesztesetek. Update: De TDD nélkül is használható egy ilyen eszköz. Ilyenkor tesztesetek nélkül, egyszerűen azt kell megnézni, hogy némi működés -némi kattintgatás- után a program mely részei kapnak vezérlést. Az összes funkción végigzongorázva a holtággá vált kódrészeket végülis ki lehet így szűrni, egy adott funkció megpendíténél pedig meg lehet találni kilóra hogy a funkció a kód mely részeit hajtja meg.

Másik, nem túl triviális célja annak jelzése, hogy az összes teszt lefuttatása során a tesztkód hány százaléka fut le. Ennek 90-100 százalék közelében kell lennie. Ha ennél alacsonyabb akkor vagy ki vannak ütve tesztesetek -amit illik megindokolni- vagy valamiért nem kerül bele az összes teszteset a suite-be, vagy a tesztkód szerkezete nem megfelelő. Unit teszteknél nem szabad körmönfont vezérlési szerkezeteket használni, nem elfogadható hogy egy adott teszteset kódja nem fut le teljes egészében (100%). If-nek például elvileg egyáltalán nem szabadna tesztkódban lennie, legfeljebb utility osztályban. Egyébként az 5-10 százalék veszteség is valószínűleg a utility osztályokban kell hogy legyen.

1-2% veszteséget a lefedettségmérő eszköz is csinál mérési hibaként. Majd ideírom amikor megint találkozom vele, de úgy emlékszem a finally blokkban lévő kódot nem számolja, valamint az inicializáló blokkokkal is mintha meggyűlt volna a baja. Szóval a 98-99 százalékot néha lehet 100-nak venni már.

Reverse engineering-nél lehet érdekes azt megnézni, hogy egy adott teszteset vagy adott funkció a kód mely részeit hajtja meg. Ránézésre látni kilóra, hogy mely package-ek osztályok és metódusok kaptak vezérlést, miket érdemes a későbbiekben figyelemmel kísérni. Nekem hasznos volt ez a felhasználási mód is néhány alkalommal, amikor más kódjával ismerkedtem.

És végül amiért most ismét elővettem ezt az eszközt: 3rd party komponensek lefedettségét is meg lehet vizsgálni. Éppen egy webstart alkalmazáson dolgozom hobbiszinten, ami használ egy-két külső könyvtárat, de csak egy-két funkció erejéig. Az egyszerűség kedvéért az egész hóbelevancot egy jar-ba csomagolom és arra gondoltam ki fogom ütni a nem használt osztályokat a külső könyvtárakból a buildelés során. Most 1.3 mega a jar, jó lenne lemenni a harmadára. Bár az az érzésem hogy van erre jobb céleszköz is.

Egy-két régi Ant-os projektünket is szívesen végigbogarásznék egy ilyen lefedettségmérővel, mert ott már a világ összes jar-ja benne volt a lib könyvtárban. A Maven-nel már más a helyzet, mert az már ügyel a függőségek kezelésére -mondhatná egy Maven-hívő- de azért ott sem ilyen egyszerű a kép. Néha azért csattogtatni kell a exclusion-okat, mert pl. a log4j-hez is összeszed minden szutykot amit nem is akarok használni.

Remélem sikerült lefednem a kódlefedettségmérés felhasználási lehetőségeit. Jó pénteket!