You are here

Automata tesztek refaktorálása

Hungarian
Body: 

Az elmúlt két napban automata teszteket refaktoráltam és két alapelv felrúgása miatt csinálnom kellett egy csomó (~1000 sor) duplikálást, mert elsődleges szempont az, hogy a tesztek működjenek és legyen egy bármikor használható regressziós csomag.

A tesztek készítésének folyamata

Az ügyfelünktől az elemzők megkapják azt, hogy milyen funkciók legyenek megvalósítva. Ehhez az elemzők sztorikat gyártanak és minden sztori (story) tartalmaz kritériumokat (acceptance criteria) , amelyek teljesülése esetén a sztorira úgy fogunk tekinteni, hogy az készen van, de nincsen tesztelve. Ezt követően, mi tesztelők, a kritériumok alapján tesztekek készítünk a Quality Centerben. Itt egy-egy kritérium egy-egy teszttel van lefedve. Ennek oka az, hogy a kritériumok változhatnak és változnak is elég sűrűn. Azzal, hogy egy-egy kritéium egy-egy teszttel van lefedve megóvjuk magunkat attól a kíntól, hogy gyakorlatilag újra kelljen írni a fél világot ha egy-egy kritérium változik. Szép szakmaisággal kifejezve magam azt mondom, hogy ilyen módon ez az impakt faktor alacsony szinten van. Ennek az egy-egy- kritérium egy-egy teszt a QC -ben az lehet a következménye, hogy ha ezekből a tesztekből csinálunk egy regressziós csomagot (mindegy, hogy automatizált vagy sem) a csomag futási ideje sokkal több lehet, mintha logikusan, a futási időre is koncentrálva, kritériumok tesztelését összevonva egy-egy tesztbe csinálnánk. Igen, ez az a pont, ahol kompromisszumokat kell kötni. De ez már egy másik téma és egy másik bejegyzés.

Az QC-ben elkészült teszteket automatizáljuk. Itt is egy-egy automata teszt egy-egy tesztnek felel meg a QC-ben. Így tudjuk követni azt, hogy mi van automatizálva és mi nincsen, illetve nem kell kommentelési világbajnokságot rendezni és rászólni a másikra, hogy javítsa ki azt a kommentet.

Automatizálás

Automatizálás során pár alapelvet követünk. Az egyik, hogy screen obejtkumokat használunk. Egy-egy screen objektum tartalmazza egy-egy felületi elem tulajdonságait és viselkedéseit. Például egy gomb (button html elem) esetében tartalmazza azt, hogy többek között milyen felirattal rendelkezik a gomb és van neki egy click() metódusa, amely pontosan megfelel annak, amikor a felhasználó a gombra kattint. Ezeket az objektumokat egymásba tudjuk ágyazni és így bonyolultabb felületi elemeket is le tudunk írni aránylag egyszerűen és gyorsan. Ezek a screen objektumok tartalmazzák azt is, hogy a felületi elemek milyen lokátorokkal (Seleniumot) rendelkeznek.

A második, hogy azokat a funkciókat, amelyek nem a felületi elemek viselkedésével kapcsolatosak, hanem az oldal funkcionalitását írják le vagy éppen a Selenium funkcióit valósítják meg (c# -ban ISelenium interfész), csoportosítva, helper osztályokba gyűjtjük. Ezek a helper osztályok statikusak és aktívan használják a screen objektumokat.

A harmadik, hogy egy-egy teszt implementálása során maga a teszt kódja csak nagyon szorosan a teszttel kapcsolatos dolgokat tartalmazhat és semmi más implementációt sem. Ha implementálni kell valamit, akkor annak vagy a screen (felületi elem viselkedése) vagy a helper (oldallal kapcsolatos funkció) osztályok egyikébe kell kerülnie. Hogy érthető legyen itt egy példa. A teszt implementációba nem rakom bele azt, hogy egy felületi elemet kinyílik vagy becsukódik. Ez bele kell, hogy kerüljön a screen objektumba, mint viselkedés és a tesztbe csak az kerülhet bele, hogy az adott objektum expand() vagy collapse() metódusát meghívom. A teszt implementációba az sem kerülhet bele, hogy ellenőrzöm, hogy az adott felületi elem ki van-e nyitva vagy sem. Erre kell, hogy tartalmazzon a screen objektum egy-egy metódust isCollapsed() néven és a tesztben csak ezt hívom meg.

A refaktorálás során arra jutottam, hogy nem használunk jó nevezéktant sem. A teszt osztályaink nevei nem voltak egyértelműek, mert nem utaltak arra, hogy melyik sztorihoz tartalmaznak teszteket. Arról nem is beszélve, hogy egy-egy teszt osztály több sztorihoz tartozó teszteket tartalmazott. Itt egy huszárvágással azt csináltam, hogy egy teszt osztály csak egy sztorihoz tartalmazhat teszteket és az osztály neve Story[sztori száma] kesz. Így egyértelműen látszik az, hogy melyik sztorihoz tartozó tesztekről van szó. Egy-egy ilyen osztályon belül minden metódus tartalmaz arra utalást, hogy melyik QC szkriptet implementálja, de itt már szabadon lehet, sőt kell is, elnevezni a tesztet és így vannak ilyen teszt elnezéseink, mint a következő CheckingWhetherUsernameIsShown_Story001_010. Ezen utóbbit azért csinálom így, mert a regressziót futtató alkalmazásunkban is látnunk kell, hogy melyik teszt melyik sztorihoz tartozik.

A refaktorálás során mivel követtem azt az elvemet, hogy egy-egy teszt osztály csak egy-egy sztorihoz tartozó teszteket tartalmazzon szét kellett pakolnom a meglévő szkriptjeinket és mivel azok az alapelveink nem voltak követve, hogy screen és helper osztályokat használunk csinálnom kellett megközelítőleg 1000 sornyi duplikációt. Ezek azok, amelyeket át kell írni, mert ez 1000 sornyi olyan kód, amely fölösleges és karban kell tartani.

 

Sayusi's tagcloud: