Az iOS-eszközök még mindig a mobilpiac jelentős részét, a globális eladások 22 százalékát teszik ki. Mivel sok elkötelezett ügyfél tér vissza az új Apple-termékekért, az iOS-alkalmazások iránt is nagy a kereslet. Ebben a cikkben az iOS-alkalmazások minőségének biztosításával foglalkozunk, törekedve a legjobb gyakorlatok alkalmazására az Appium, a Cucumber és a Serenity eszközök segítségével.

Szerkezet

A Page Object Model az egyik legjobb megközelítés a teszteléshez, amelyet a QA mérnökök alkalmazhatnak egy teszt automatizálási projektben. Ez egy olyan módja a kód strukturálásának egy automatizálási projektben, amely javítja a kód minőségét és olvashatóságát, a tesztek karbantartását, és ráadásul nagyszerű módja a káosz elkerülésének. Az alapötlet mögötte az, hogy az alkalmazás minden egyes oldalára vagy képernyőjére (vagy nem natív webes alkalmazások esetén a weboldalra) egyetlen osztályfájlban tartjuk a mobil elemekre és a rajtuk műveleteket végző metódusokra való összes hivatkozást.

Mi az előnye ennek a megközelítésnek, kérdezheti? Először is, nagyon egyszerűvé teszi az automatizálást. Alapvetően azt jelenti, hogy az iOS-alkalmazásunkban az inspektoron keresztül megkeressük az elemeket, majd műveleteket hajtunk végre rajtuk. A másik fő előnye a projekt koherens felépítése, amely lehetővé teszi, hogy bárki gyorsan eligazodjon benne.

Vegyünk egy példát egy olyan alkalmazásról, amely recepteket tartalmaz. Indításkor az alapértelmezett szakácskönyvet jeleníti meg az alapvető receptekkel, ami az első oldalunk lesz. Onnan a felhasználó bármelyik elérhető receptre navigálhat, így jelölve egy második oldalt. Ezen felül az alkalmazás lehetővé teszi más szakácskönyvek böngészését vagy prémium szakácskönyvek vásárlását is, ami a harmadik oldalt és következésképpen – egy oldal objektumfájlt jelent.

Hasonlóképpen, nekünk is létre kell hoznunk a megfelelő lépésdefiníciós fájlokat. Ez nem kötelező gyakorlat, de az összes lépésdefiníció egy helyen tartása felesleges káoszt okoz.

Az oldalak és a lépésdefiníciós osztályfájlok létrehozása során célszerű olyan neveket választani, amelyek ahhoz az oldalhoz (alkalmazás képernyőjéhez) kapcsolódnak, amelynek tartalmán dolgozni fogunk. Ha ezeket a fájlokat egy funkció vagy forgatókönyv után nevezi el, az első pillantásra helyesnek tűnhet, de ahogy a projekt bővül, egyre nagyobb rendetlenséget fog észrevenni a szerkezetében. Az oldalelnevezési konvenció elfogadása biztosítja, hogy a projektben részt vevők azonnal megismerkedhessenek vele, és pillanatok alatt megkezdhessék az együttműködést rajta. Ez a gyakorlat a kód – akár a lépésdefiníciók, akár a metódusok/funkciók – újrafelhasználhatóságához is hozzájárul.
Az említett lépés- és lépésdefiníciós fájlokkal ellentétben a Cucumber funkciófájlokat az általuk ellenőrzött funkcióról kell elnevezni. Okos, nem igaz? És ismét, ha a tesztelt alkalmazás egy adott területével kapcsolatban elnevezett könyvtárakba strukturáljuk őket, akkor a struktúra értelmesebb lesz.
A Serenity alapkoncepciója az, hogy egy “élő dokumentáció” legyen. Ezért a tesztforgatókönyvek és a funkciófájlok megfelelő elnevezése segít a csapatnak és az érintetteknek jobban megérteni a jelentéseket és az egész projektet.

A Page Object Model előnyeit a tesztautomatizálási projektben bővítő másik összetevő a PageFactory. Ez egy olyan eszköz, amely segít a kódolási munka csökkentésében és a MobileElements lokátorok egyszerű elhelyezésében a kódban, a @FindBy jelölés használatával. Innen kezdve sokkal egyszerűbb az elemek megtalálása az Appium számára, hogy a tesztekben kölcsönhatásba léphessen velük.

Assertion

A tesztek futtatása az Appiumon keresztül nagyon erőforrásigényes lehet. Annak érdekében, hogy megkönnyítsük a MacOS-gépen az iOS-eszközön futó tesztek futtatását, győződjünk meg róla, hogy nem állítjuk folyamatosan az összes objektum láthatóságát egy oldalon. Ez a gyakorlat jelentősen megnöveli a tesztek végrehajtási idejét, ami általában nem a legkívánatosabb dolog.

Mégis, ha ellenőrizni kell, hogy egy elem látható-e, engedélyezett-e, kattintható-e, vagy bármi a kettő között – próbálja meg elkerülni a mobil elemek Xpath segítségével történő lokalizálását. Az Appium inspector tippje jogos! Mindent meg kell tenned, hogy meggyőzd a fejlesztőcsapatot, hogy tegyenek extra erőfeszítést, és rendeljenek egyedi azonosítókat és neveket az alkalmazás elemeihez. Ez nem csak az automatizálási tesztelést teszi egyszerűbbé és gyorsabbá, következésképpen az Ön tesztelői munkáját is hatékonyabbá teszi, ami végső soron a termék általános minőségének növekedését eredményezi. És ezért vagyunk mi itt. Arról nem is beszélve, hogy a tesztek karbantartása (pl. szükség esetén más lokátorokra váltás) sokkal élvezetesebbé válik.

A lépések megértése

Az ilyen típusú projekt felállításának másik szempontja a Cucumber előnyeinek kihasználása és a Gherkin nyelv használata.

A Gherkin a Given, When, Then jelöléssel egy egyszerű megközelítést valósít meg a kiegészítő And és But segítségével, ami meglehetősen könnyen használhatónak tűnik. Nagyjából bármit írhatsz a funkciófájljaid tesztlépéseibe, amit csak akarsz. Végső soron a meghívott metódusok műveleteket fognak végrehajtani.

A Behavior Driven Development megközelítés és maga a Cucumber használatának oka azonban az, hogy a projektben részt vevő nem technikai emberek számára is lehetővé teszi, hogy megértsék, mi történik a tesztek területén. Nem csak ez, a tesztforgatókönyvek Given/When/Then módon történő megírása is az előnyünkre válhat. Az ilyen, az ügyfél vagy az üzleti elemző által szállított magas szintű tesztleírások pillanatok alatt kódolásra késztetnek, feltéve, hogy megfelelően vannak megírva. Íme néhány hasznos tipp:
A Gherkin nyelven írt tesztforgatókönyveknek az alkalmazás viselkedésére kell összpontosítaniuk (ezért Behavior Driven Development).
Itt egy példa arra, hogyan NE írjunk tesztforgatókönyveket Gherkinben, tovább boncolgatva a szakácskönyv alkalmazás témáját:

A fenti példa két rossz gyakorlatot szemléltet, amelyeket kerülnünk kell: A viselkedés helyett az implementációra összpontosít, és keményen kódolt értékeket használ ahelyett, hogy a tesztlépéseket úgy írná meg, hogy lehetővé tegye az újrafelhasználhatóságot az értékek lépésen belüli megváltoztatásával.

Ezért egy megfelelő forgatókönyvnek a szakácskönyv megvásárlására vonatkozóan a példaalkalmazásunkban így kellene kinéznie:

Egy másik példa:

Egy ilyen megközelítés alkalmazása kevesebb munkát jelent a tesztlépések létrehozásában és kódolásában, amikor egy adott funkció megvalósítása megváltozik.

A Given/When/Then fő jelölés mellett a Cucumber támogatja a konjunkciós lépések használatát. Az And és But lépés jelölések használata általánossá és újrafelhasználhatóvá teszi a tesztlépéseket, ami kevesebb kód írását és a projekten belüli rend fenntartását eredményezi. Íme egy alapvető példa:

Ha a fenti ‘Given’ lépést úgy kódoljuk, hogy a receptelemünket a nevének keresésével keressük meg, akkor azt sokszor újra felhasználhatjuk, csak a lépés string értékét kell megváltoztatnunk (feltéve, hogy később megfelelően kódoljuk a lépésdefiníciót). Ráadásul az ‘And’ lépés bármely olyan tesztforgatókönyv része lehet, amely ilyen műveletet tartalmaz.

Az egészet összerakva

A fent leírt gyakorlatokat alkalmazó projekt beállítása után a Serenity használatának leglátványosabb részei a generált tesztjelentések. Miután elfogadta a @RunWith(CucumberWithSerenity.class) taget a TestRunner osztályfájljában, a tesztcsomag futtatása után a Serenity egy összesített teszteredmény-jelentést generál, amely hasznos lehet a tesztelt alkalmazás minőségének értékelésében és a termék állapotának bemutatásában az érdekeltek vagy a fejlesztőcsapat számára.

Appium, Cucumber, Serenity – Összefoglalás

Mint látható, az automatizálási tesztelés legjobb gyakorlatainak fogalma három szóban foglalható össze: újrafelhasználhatóság, olvashatóság és teljesítmény. Az újrafelhasználhatóság kevesebb kódolást jelent, következésképpen csökken a feladat elvégzéséhez szükséges idő. Az olvashatóság javítja a megértést, ami kulcsfontosságú annak biztosításához, hogy a termék azt tegye, amit tennie kell. Végül a teljesítmény megtakarítja a végrehajtási időt és javítja a stabilitást. Mindhárom nem csak a tesztautomatizálási projekt minőségéhez járul hozzá, hanem jelentős szerepet játszik a leszállított alkalmazás általános minőségének javításában is.