Weblabor

Érdekes dolog ez. A napokban/hetekben sokat beszélgettem erről és a kapcsolatos dolgokról az egyik kollégámmal. Már eleve az nem egyértelmű, mi is a unit teszt, mi a unit? :)

Abban a legtöbb programozó egyetért, hogy költséges a tesztek karbantartása, egy kis változtatási igény is rengeteg tesztet érinthet. Ez senkinek se jó. Ennek a legtöbbször a rengeteg mock az oka. Véleményem szerint normális architektúrával elérhető az, hogy viszonylag kevés és viszonylag jól körülhatárolható területet kell, és lehet csak úgy lefedni tesztekkel, hogy mockokat kelljen használni. Ez a videó rávilágít erre, de legalábbis elgondolkodtatja az embert.

Janoszennel egyetértek, behaviourt kell tesztelni, ez viszont nem jelent integrációs tesztelést. Ha csak kényszeresen kimockolsz mindent és a kódod legmélyét teszteled anélkül, hogy a teszted egy valós felhasználási esetet szimulálna, akkor az a teszt nem sok mindenre jó. Ha két hét múlva eltörik, fogalmad sem lesz arról, miért törik, egyáltalán hogy mit is tesztel valójában és ezen a gondosan megválasztott tesztmetódus elnevezés sem segít. Ez oda vezet, hogy ignorálod/kikommentezed, végül törlöd, ez pedig óriási rizikófaktor.

Itt például azt tesztelem, hogy egy feldolgozatlan üzenetet a messabus újra elküld-e egy DeadMessage objektumba csomagolva. A message busnak van néhány függősége, amiket kimockolhatnék és tesztelhetném a belső állapotokat. Valójában amire kíváncsi vagyok, hogy az előbbi viselkedést produkálja-e a bus. Ez azonban nem integrációs teszt. Nem használ külső erőforrást, nem ír/olvas fájlt/hálózati erőforrást/adatbázist, stb.

Azt talán a legtöbb, unit tesztet aktívan használó programozó tudja, hogy a coverage szükséges, de nem elégséges: valódi tesztelés nélkül is meg lehet hajtani a production kódot. Viszont valóban jó teszteket írni egyáltalán nem egyszerű :)