Az UI tesztelés automatizálása iOS-en olyan egyszerűvé vált, mint a unit tesztek írása, amióta az Apple bevezette az XCUI keretrendszert. Ebben a bejegyzésben arról fogok beszélni, hogy az XCUI a réteges tervezéssel párosítva hogyan segíthet könnyedén automatizálni az alkalmazásokat, különösen azokat, amelyek több testreszabott UI-elemet tartalmaznak. Az egyik ilyen alkalmazás, ahol ezt széles körben használtuk, a VMware Boxer, egy vállalati alkalmazás a VMware-től, amely három fontos funkciót – Email, Naptár és Kapcsolatok – egyesít. A VMware Boxer többféle UI-elemet használ a natív UITableView-tól az erősen testreszabott vizuális elemekig.
Feltételezzük, hogy az olvasó rendelkezik alapvető ismeretekkel az Xcode, az Objective C, a Swift, az XCUI keretrendszer és általában az Apple fejlesztői ökoszisztéma területén. Ha még nem ismeri az XCUI-t, érdemes először itt kezdenie.
Mint minden más UI-automatizálási projekt, a mi csapatunk is azzal a kérdéssel kezdte, hogy melyik automatizálási keretrendszert használjuk. Mi a SeeTestet használtuk. Ezt azonban lehetőségnek láttuk arra, hogy felülvizsgáljuk az automatizálási stratégiánkat, tekintettel a VMware Boxerben hozzáadott új, összetett funkcionalitásra, a VMware ökoszisztémájához tartozó termékek számára és a termékek közötti integrációs tesztelésre. Az alábbiakban az általunk mérlegelt választási lehetőségek következtek-
1. Továbbra is SeeTest
2. Earl Grey
3. XCUI
Míg a SeeTest képes volt kezelni a közvetlen automatizálási igényeinket, volt egy független kihívás, amellyel meg kellett küzdenünk. Ez egy új technológiai stack bevezetését követelte meg tőlünk. Ez további képzést igényelt volna az iOS-fejlesztők számára, valamint dedikált szakértőket az automatizálási rendszer karbantartásához.
Mi a helyzet az Appiummal? Az Appiumot a SeeTest esetében említett okok miatt nem vettük figyelembe. Az Appium akkor lenne jó választás, ha hibrid alkalmazásaink lennének, vagy jelentős megosztott kóddal rendelkeznénk az Android és az iOS között.
Az Earl Grey 1 egy lehetséges választás volt, mivel lehetővé tette, hogy az Xcode és az Apple fejlesztői eszközeiben maradjunk, és az XCTestre épült. Az Earl Grey 1 automatizálás azonban ugyanabban a folyamatban fut, mint a tesztelt alkalmazás. Ezzel szemben az Apple XCUI keretrendszeren alapuló automatizálása a tesztelendő alkalmazástól különálló folyamatban fut. Ez előnyös, mivel a tesztelés alatt álló alkalmazás nem lehet más, mint egy fekete doboz a felhasználói felületét tesztelő entitás (automatizálási folyamat vagy végfelhasználó) számára.
Az automatizáló (tesztelő) folyamatot el kell különíteni a tényleges tesztelés alatt álló alkalmazástól. A tesztelés alatt álló alkalmazás nem lehet más, mint egy fekete doboz az automatizáló folyamat számára.
Az Apple ökoszisztémában minden olyan új eszköz, amely nem igazodik az Apple megközelítéséhez (pl. Earl Grey 1), figyelmeztetés nélkül megbukhat. Egy ilyen megközelítés fenntartása sok erőfeszítést igényelhet, hogy továbbra is működjön az Apple újabb vagy jövőbeli ajánlataival.
Az Earl Grey 2 hozzáadta az XCUI-val való interakció képességét. Ez egy kísérlet volt az XCUI-hoz való igazodásra, de megvoltak ezek az ismert problémák.
Az XCUI végül az előnyben részesített választás lett. Ezzel a fejlesztő nagyobb kontrollt kap az automatizálás felett, és közvetlen haszonélvezője lesz minden innovációnak az Apple ökoszisztémájában.
Tesztelés alatt álló alkalmazás és az XCUI automatizálási modul
Mielőtt belevágnánk a részletekbe, fontos megismételni, hogy az XCUI-t használó automatizálási modul a tesztelés alatt álló alkalmazástól független folyamatként fut. Kezdetnek hozzáadtunk egy új modult, amelyre a továbbiakban automatizálási modul(AM) néven fogunk hivatkozni. Az AM egy olyan munkaterület, amely az XCUI-t használó VMware Boxer automatizáláshoz használt osztályok és adatstruktúrák gyűjteményét tartalmazza.
A hozzáférhetőségi azonosítók
Nagyon fontos, hogy az alkalmazást a tesztelhetőséget szem előtt tartva fejlesszük. A fejlesztő egyik felelőssége annak biztosítása, hogy a fejlesztés során minden egyes, a végfelhasználónak kitett felhasználói felületelemhez be legyen állítva az elérhetőségi azonosító. A hozzáférhetőségi azonosító a kapcsolat a tesztelt alkalmazás és az XCUI automatizálási folyamat között.
A hozzáférhetőségi azonosító a kapcsolat a tesztelt alkalmazás és az XCUI automatizálási folyamat között.
Tervezési minta
Mint korábban említettük, a VMware Boxer egy hatalmas alkalmazás. Az alkalmazandó tervezési minta kiválasztásakor azt tartottuk szem előtt, hogy a teszteknek könnyen megvalósíthatónak, könnyen karbantarthatónak, újrafelhasználhatónak, robusztusnak és skálázhatónak kell lenniük. Az alábbi tartalom a VMware Boxerhez készült XCUI automatizálási modul felépítésének rétegeit ismerteti:
A következő ábra az alapvető építőelemeket mutatja:
Tesztosztályok
Ez a réteg tartalmazza a tesztmódszerekkel rendelkező osztályokat. Ennek a rétegnek az a célja, hogy a tesztek minimális kódból álljanak, amely csak azt mondja ki, amit tesztelünk. Továbbá a teszteket végrehajtó fejlesztőnek csak a teszteléshez szükséges magas szintű alkalmazásfolyamatra kell gondolnia. Az összetettség többi részét (pl. hogyan navigáljunk a felhasználói felületre, ahol a kívánt tesztelés elvégezhető) újrafelhasználható rétegekbe kell absztrahálni. Lásd az alábbi képet, amely egy példa tesztmódszert mutat, amely a fenti szándékot magyarázza – a kód azt teszteli, hogy a Beállítások felhasználói felület segít-e egy funkció engedélyezésében/letiltásában, vagy rendelkezik-e a szükséges kapcsolóvezérlőkkel.
A teszteket író fejlesztő tehát olyan egyszerű kódot írhat, mint az álkód. Eközben nyilvánvaló, hogy bizonyos logikát a következő rétegből (Flows : a következő szakaszban kifejtve) kell meghívni.
Flows osztályok
A Flows olyan osztályok gyűjteményét jelenti, amelyek a különböző Tests osztályokhoz szükséges funkciókat biztosítják. A funkcionalitások közé tartozhat az alkalmazás beállítása a valódi teszteset végrehajtása előtt, vagy a tesztelt alkalmazás egy bizonyos részéhez való navigálás. A legtöbb ilyen funkcionalitás újrafelhasználható, és több tesztben is szükséges. pl. a fenti minta teszteset megköveteli, hogy 1. az alkalmazás elinduljon. és 2. az applikáció elinduljon. Egy Feature Controller beállítások képernyőjére navigálunk.
A Flow osztályokat tehát a tesztekből hívnánk meg, és olyan áramlásokat valósítanánk meg, mint a “Navigálás a beállításokhoz” vagy a “Navigálás a Feature Controller beállításaihoz”.
Screens osztályok
A képernyők olyan osztályok, amelyek egy az egyben leképezéssel rendelkeznek a megfelelő View Controllerekhez. Egy View Controller magas szinten egy olyan osztálynak tekinthető, amely rendelkezik (a háttérben lévő nézetben) UIControlokkal és olyan metódusokkal, amelyek reagálnak a felhasználó interakciójára ezekkel az UIControlokkal. A Screen osztály egyszerűen a View Controller proxy leképezése. Az alábbi ábra mutatja ezt a leképezést. A felhasználói felületen van egy Initial View (Kezdeti nézet) cella, és amikor a felhasználó rákoppint erre a cellára, a felhasználó kiválaszthatja, hogy mi legyen az alkalmazás kezdeti nézetének jelölve. Az alábbi ábrán látható, hogyan valósul meg egy Screen osztály a fenti követelmény leképezéséhez.
A képernyő osztály pszeudo kódja így nézne ki –
// The class models the SettingFormViewController for XCUI tests.public class SettingsFormScreen {
private static let navBarId = "Boxer.Settings.NavigationBar"
private lazy var featureControllerCell = boxerApp.application.tables.cells public func navigateToFeatureController() -> Bool {
return // tap on Cell with featureControllerCellId
}
}class AccessibilityIdentifiers: NSObject {// MARK: Settings Screenstatic let featureControllerCellId = "Boxer.Settings.FeatureControllerCell"
}
Mi a boxerApp a fenti kódban? A fenti kódban a boxerApp egy egységet képvisel, amely a BoxerApp osztály egy példánya, amely a tesztelt alkalmazást és annak képernyőit foglalja magába. Ezt a következő szakaszban ismertetjük.
A fenti kód a VMware Boxer SettingFormViewControllerét modellezi. Az osztály elnevezésénél alkalmazott konvenció szerint a név a ViewController utótag Screenre történő cseréjével a ViewController nevéből származik. Figyeljük meg a kényelmi osztályt is, amely hozzáférhetőségi azonosítókkal rendelkezik.
A hozzáférhetőségi azonosító a közös kapocs a tesztelt alkalmazás és az XCUI automatizálási folyamat között.
Összeállítás: VMware Boxer XCUI automatizálási modul
Az UITest modul teszteli a futó alkalmazást. Fontos, hogy az alkalmazásmodell úgy legyen kialakítva, hogy a tesztelt alkalmazás egy példánya egyetlen egységet képezzen. Ez azt jelenti, hogy a tesztelt alkalmazást úgy kell tekinteni, mint az üzleti folyamatokban részt vevő képernyőosztályok gyűjteményét (áramlási osztályok gyűjteménye)amelyeket a tesztek (osztályok gyűjteménye)a teszt követelménye alapján hívnak meg. Minden alkalmazásegységnek pontosan egy példányt kell tartalmaznia minden Screen osztályból, amely egy nézetvezérlőnek felel meg.
Hogyan lehet ezt elérni?
Egy XCUITestcsomag ezt úgy érheti el, hogy a tesztelendő alkalmazást (XCUIApplication) egy egységbe kapszulázza, pl. BoxerApp osztály, amelynek van egy tagalkalmazása, és amely tartalmazza az alkalmazás összes képernyőjét. Az alábbi ábra magyarázza ezt a kapszulázást
Ezért mielőtt az XCUITest csomag elindulna, az első dolga az lenne, hogy létrehozza a BoxerApp modul egy példányát a tesztelendő alkalmazás csomagazonosítójával. Az alábbi ábra ezt magyarázza
A BoxerApp (az XCUIAplikációt és a képernyőket kapszulázó egység) ezen példányát a Tests::testMethod ezután első paraméterként átadja a Flows::flowMethodnak.
A Flows::flowMethod viszont felhívja a Screen::screenMethod-ot, és szükség esetén átadja a BoxerApp-ot.
Az alkalmazás felhasználói felületével való interakció végül a Screen::screenMethodon keresztül történik.
Az alábbi ábra a fenti kialakítást mutatja.
Következtetés
Az XCUI tesztek írása nehézkes és kezelhetetlen lehet, ha nem tervszerűen történik. Remélem, ez a bejegyzés hasznos támpontokat ad ahhoz, hogyan gondolkodjunk az automatizálási projekt moduláris, tiszta, rétegzett módon történő felépítéséről.
Mi következik?
Ezekkel a témákkal fogok foglalkozni az általam tervezett történetsorozatban:
XCUI : 2. rész -A natív alkalmazásokkal való tiszta interakció
XCUI : 3. rész -Hogyan tud az XCUI futásidő a tesztelt alkalmazással tiszta módon interakcióba lépni.
XCUI : 4. rész -A rendszerjelzések kezelése.
XCUI : 5. rész -A teszt előrehaladásának megfigyelése, a jelentések elérése és a képernyőképek rögzítése.