Univerza v Ljubljani
Fakulteta za raˇ cunalniˇ stvo in informatiko
Andrija Kuzmanov
Avtomatizacija testiranja mobilnih aplikacij
DIPLOMSKO DELO
UNIVERZITETNI ˇSTUDIJSKI PROGRAM PRVE STOPNJE
RA ˇCUNALNIˇSTVO IN INFORMATIKA
Mentor : doc. dr. Luka F¨ urst
Ljubljana, 2022
besedilo, slike, grafi in druge sestavine dela kot tudi rezultati diplomskega dela lahko prosto distribuirajo, reproducirajo, uporabljajo, priobˇcujejo javnosti in pre- delujejo, pod pogojem, da se jasno in vidno navede avtorja in naslov tega dela in da se v primeru spremembe, preoblikovanja ali uporabe tega dela v svojem delu, lahko distribuira predelava le pod licenco, ki je enaka tej. Podrobnosti licence so dostopne na spletni strani creativecommons.si ali na Inˇstitutu za intelektualno lastnino, Streliˇska 1, 1000 Ljubljana.
Izvorna koda diplomskega dela, njeni rezultati in v ta namen razvita program- ska oprema je ponujena pod licenco GNU General Public License, razliˇcica 3 (ali novejˇsa). To pomeni, da se lahko prosto distribuira in/ali predeluje pod njenimi pogoji. Podrobnosti licence so dostopne na spletni strani http://www.gnu.org/
licenses/.
Besedilo je oblikovano z urejevalnikom besedil LATEX.
Kandidat: Andrija Kuzmanov
Naslov: Avtomatizacija testiranja mobilnih aplikacij
Vrsta naloge: Diplomska naloga na univerzitetnem programu prve stopnje Raˇcunalniˇstvo in informatika
Mentor: doc. dr. Luka F¨urst
Opis:
V diplomski nalogi opisujemo, kako testirati mobilne aplikacije z enim na- borom kode. Opisani pristop bomo primerjali z domorodnimi ogrodji za platformi Android in iOs.
Title: Automation of mobile application testing Description:
In this thesis, we will describe how to test mobile applications with a sin- gle code base. We will compare the presented approach with the native frameworks for the platforms Android and iOs.
Zelel bi se zahvaliti svojim starˇˇ sem in babicam ter dedkom, ki so me skozi celoten ˇstudij podpirali.
Kazalo
Povzetek Abstract
1 Uvod 1
2 Pregled podroˇcja 3
2.1 Testiranje programske opreme . . . 3
2.2 Funkcionalno testiranje . . . 4
2.3 Avtomatizacija testiranja . . . 5
3 Orodja in tehnologija 7 3.1 Selenium Webdriver . . . 7
3.2 Appium . . . 7
3.3 Pytest . . . 10
3.4 Naˇcrtovalski vzorec Page Object . . . 12
3.5 Espresso . . . 14
3.6 ADB . . . 14
3.7 XCUITest . . . 14
3.8 YAML . . . 15
4 Implementacija 17 4.1 Opis implementacije . . . 17
4.2 Testi v orodju Pytest . . . 20
4.3 Osnovni primer . . . 22
4.6 Konfiguracija . . . 34
4.7 Datoteˇcna struktura . . . 35
5 Primerjava orodij 37 5.1 Testna aplikacija . . . 37
5.2 Testni primeri . . . 40
5.3 Pridobivanje elementov . . . 42
5.4 Interakcije z elementi . . . 43
5.5 Preverjanje trditev . . . 46
5.6 Testni primer . . . 47
5.7 Primerjava hitrosti in zanesljivosti . . . 48
6 Rezultati 51 6.1 Pridobljeni rezultati . . . 51
6.2 Sploˇsno . . . 52
6.3 Primerjava z ogrodjem Espresso . . . 52
6.4 Primerjava z ogrodjem XCUITest . . . 53
7 Zakljuˇcek 55
Clanki v revijahˇ 59
Celotna literatura 61
Seznam uporabljenih kratic
kratica angleˇsko slovensko
HTTP HyperText transfer protocol protokol za prenos hiperteksta JSON JavaScript Object Notation Objektna notacija za JavaScript
API Application Programming Interface vmesnik uporabniˇskega programa XML Extensible Markup Language razˇsirljiv oznaˇcevalni jezik
URL Uniform Resource Locator enoliˇcni krajevnik vira
Povzetek
Naslov: Avtomatizacija testiranja mobilnih aplikacij Avtor: Andrija Kuzmanov
V diplomski nalogi predstavljamo, kako lahko z enim naborom kode testiramo grafiˇcne vmesnike mobilnih aplikacij tako za platformo iOs kot za platformo Android. Opisani pristop k testiranju primerjamo s testiranjem z uporabo domorodnih ogrodij za omenjeni platformi. Namen dela je pokazati pred- nosti in slabosti takˇsnega testiranja ter s tem pomagati pri izbiri orodja za testiranje grafiˇcnih vmesnikov mobilnih aplikacij.
Avtomatizacija testiranja programske opreme je danes izrednega pomena, saj zniˇzuje stroˇske in pospeˇsuje proces testiranja. V okviru tega diplomskega dela obravnavamo delovanje, arhitekturo in implementacijo testov z orodjema Appium in Pytest. Implementirane teste nato primerjamo z domorodnimi testi za platformi iOs in Android. Dobljene rezultate analiziramo in komen- tiramo.
Kljuˇcne besede: testiranje, Appium, aplikacije.
Abstract
Title: Automation of mobile application testing Author: Andrija Kuzmanov
In this thesis, we present how to test the user interface of mobile applications for both the iOs and Android platform using a single code base. We compare the described approach to testing with approaches that use native frameworks for iOs and Android. The purpose of this work is to present the advantages and disadvantages of such testing and help the reader decide about the proper tool for the automation of user interface testing for mobile applications.
Nowadays, automation of software testing is of great importance, since it reduces the cost and speeds up the process of testing. In this thesis, we present the behavior, architecture, and implementation of automated tests with the tools Appium and Pytest. Subsequently, we compare automated single-code-base tests with tests for the native frameworks for each platform and comment on the results.
Keywords: testing, Appium, applications.
Poglavje 1 Uvod
Tehnologija je v zadnjih 20 letih izjemno hitro napredovala in prinesla ˇstevilne spremembe v vsakdanjem ˇzivljenju. Ena izmed najbolj vplivnih iznajdb je zagotovo mobilni telefon, ki je postal vsestransko orodje, brez katerega je danaˇsnje ˇzivljenje za marsikoga nepredstavljivo. Zaradi velike konkurence programske opreme za mobilne telefone se njena kakovost z leti izboljˇsuje, s tem pa se poveˇcujejo uporabnikova priˇcakovanja glede kakovosti in zane- sljivosti aplikacij. Danes zato ni veˇc dovolj, da pred zakljuˇckom razvoja programskega izdelka izloˇcimo vse odkrite napake, temveˇc moramo med ce- lotnim razvojem skrbeti za to, da bo napak ˇcim manj [12]. Zaradi tega je bilo treba izboljˇsati in spremeniti tehnike testiranja programske opreme. Roˇcno testiranje je postalo drago, neuˇcinkovito in prepoˇcasno, zato je avtomatizacija testiranja postala kljuˇcen del vsakega razvojnega procesa. Avtomatizirani te- sti uporabniˇskih vmesnikov so tako postali neizogiben del izdelave aplikacij [25].
V diplomski nalogi bomo predstavili, kako testirati uporabniˇski vmesnik aplikacije z enim samim naborom kode. Da bi to dosegli, bomo pri razvoju testov uporabili orodji Appium in Pytest, ki omogoˇcata pisanje testov za uporabniˇski vmesnik v jeziku Python, kar prinese moˇznost uporabe ˇstevilnih odliˇcno izdelanih in dokumentiranih knjiˇznic. Navedli bomo prednosti in po- manjkljivosti omenjenega pristopa glede na najbolj uporabljena domorodna
1
orodja za platformi iOs in Android. Tema se nam zdi relevantna, saj se je avtor diplomske naloge pri delu v industriji sreˇcal s testiranjem aplikacij tako za platformo iOs kot za platformo Android in ga je vedno zmotilo, da mora iste teste napisati dvakrat in v razliˇcnih jezikih. Menimo, da bo diplomska naloga pomagala vsem podjetjem in posameznikom, ki se ukvarjajo z razvo- jem mobilnih aplikacij, saj jim bo lahko prihranila veliko ˇcasa pri njihovem razvoju in vzdrˇzevanju. Z uporabo opisanega pristopa bi v podjetjih lahko bila samo ena ekipa zadolˇzena za testiranje uporabniˇskega vmesnika. Ena sama ekipa bi imela veˇcjo stopnjo koordinacije in manjˇso ceno za delodajalca, poleg tega pa bi lahko zagotovila veˇcjo usklajenost uporabniˇskega vmesnika med razliˇcnimi platformami. Cilj diplomske naloge je potemtakem predsta- viti alternativo dosedanjim ustaljenim naˇcinom testiranja mobilnih aplikacij in pomagati pri izbiri orodja za testiranje doloˇcene platforme.
Diplomsko delo je sestavljeno iz naslednjih poglavij:
• Uvod, kjer predstavimo problem, ki ga v diplomski nalogi reˇsujemo, in cilj, ki mu sledimo;
• Pregled podroˇcja,kjer predstavimo danaˇsnje stanje na podroˇcju av- tomatizacije testov;
• Orodja in tehnologija, kjer predstavimo uporabljena orodja in teh- nologije;
• Implementacija,kjer opiˇsemo zgradbo in delovanje naˇsega ogrodja;
• Primerjava orodij, kjer primerjamo orodja med sabo;
• Rezultati,kjer dobljene rezultate predstavimo in pokomentiramo;
• Zakljuˇcek, kjer predstavimo glavne ugotovitve diplomske naloge, str- njene v smiseln zakljuˇcek.
Poglavje 2
Pregled podroˇ cja
2.1 Testiranje programske opreme
Testiranje programske opreme je danes kljuˇcen del razvoja in vzdrˇzevanja programske opreme. Programsko opremo v procesu testiranja sistematiˇcno preverjamo, da odkrijemo napake in odstopanja od zahtev. Treba je po- udariti, da testiranje ne zagotavlja, da v programski opremi ni napak, saj ne moremo nikoli predvideti in preveriti vseh moˇznih naˇcinov uporabe oz.
vhodov in izhodov programske opreme [27].
Na razliˇcnih nivojih se uporabljajo razliˇcni naˇcini testiranja. Danes bi lahko testiranje delili na [7]:
• Testiranje enot, kjer testiramo programske enote, ki so lahko razredi objektov, funkcije ali metode objektov ali celo sestavljene komponente, ki komunicirajo preko skupnega vmesnika.
• Testiranje integracije, kjer testiramo delovanje veˇc medsebojno po- vezanih enot in komponent.
• Funkcionalno testiranje, kjer testiramo, ali je programska oprema skladna s funkcionalnimi zahtevami. Temelji na ˇze vnaprej doloˇcenih zahtevah, na podlagi katerih se doloˇcijo testni primeri.
3
• Testiranje sistema, kjer testiramo zahtevane nefunkcionalne lastno- sti sistema, ki najbolj pogosto zajemajo odzivni ˇcas, zanesljivost in prostorske zahteve.
• Sprejemno testiranje, kjer naroˇcnik preveri, ali programska oprema ustreza njegovim ˇzeljam.
• Testiranje namestitve, kjer testiramo delovanje programske opreme po namestitvi.
2.2 Funkcionalno testiranje
Pri funkcionalnem testiranju preverjamo, ali je programska oprema skladna s funkcionalnimi zahtevami. To so zahteve, ki za programsko opremo doloˇcajo, katere storitve mora ponuditi, kako se mora odzvati na doloˇcene vhode in kako se mora obnaˇsati v razliˇcnih situacijah [5]. Na podlagi teh zahtev se doloˇcijo funkcionalni testi, ki preverjajo doloˇceno funkcionalnost. Kot primer omenimo funkcionalno zahtevo za prijavo uporabnika v spletni portal, kjer bi za test izbrali razliˇcna uporabniˇska imena in gesla ter spremljali, ali se sistem pravilno odzove (kot je v zahtevah zapisano) na vse vhodne podatke.
Funkcionalno testiranje lahko razdelimo na veˇc vrst [16]:
• Princip ˇcrne ˇskatleje princip testiranja, kjer ne poznamo notranjega delovanja programske opreme.
• Princip sive ˇskatleje princip testiranja, kjer delno poznamo notranje delovanje programske opreme.
• Princip bele ˇskatle je princip testiranja, kjer v celoti poznamo no- tranje delovanje programske opreme.
Diplomska naloga 5
2.3 Avtomatizacija testiranja
Avtomatizacija testiranja je tehnika testiranja, kjer primerjamo izhod doloˇcenega programa s priˇcakovanim izhodom z uporabo testnih skript ali orodij za avto- matsko testiranje. Uporablja se zato, da avtomatizira ponavljajoˇce se naloge ali pa naloge, ki jih ˇclovek teˇzko izvede [33]. Avtomatizacija testov zaradi tega prihrani veliko ˇcasa in omogoˇca izvedbo velike koliˇcine testov v krat- kem ˇcasovnem obdobju, kar poslediˇcno zmanjˇsa potrebno ˇstevilo ljudi za testiranje programske opreme in s tem delodajalcem zniˇza stroˇske [15]. Av- tomatizirane teste izvajajo raˇcunalniki in tako poveˇcajo zanesljivost testov, saj raˇcunalnik vedno na enak naˇcin in brez napak opravi iste korake, medtem ko smo ljudje v sploˇsnem manj zanesljivi. Avtomatizacija poleg tega zmanjˇsa stroˇske vzdrˇzevanja in nadgrajevanja programske opreme, saj testne skripte sluˇzijo tudi kot dokumentacija programske opreme in ob zadostni pokritosti skrbijo za to, da pri spreminjanju ene komponente ne pokvarimo delovanja drugih komponent.
Seveda pa avtomatizacija testov ne prinaˇsa le pozitivnih stvari. Avtoma- tizacija predstavlja veliko zaˇcetno investicijo, saj se moramo nauˇciti upora- bljati in razvijati teste s pomoˇcjo orodja za avtomatizacijo testnih primerov.
Poleg tega je treba teste redno vzdrˇzevati in posodabljati na tak naˇcin, da se ujemajo z zahtevami. Moramo se tudi zavedati, da z avtomatiziranimi testi lahko testiramo le natanˇcno doloˇcene zahteve, kar pomeni, da uporabnost in intuitivnost doloˇcene programske opreme teˇzko testiramo z avtomatskimi testi [9]. Zaradi tega ne moremo zamenjati celotnega oddelka, ki skrbi za kakovost programske opreme, lahko le zmanjˇsamo ˇstevilo zaposlenih v ome- njenem oddelku.
Iz zapisanega je razvidno, da avtomatizacija testiranja ni vedno smiselna in da se je treba vpraˇsati, za kakˇsne testne scenarije bi bila primerna. Zaradi stroˇskovne uˇcinkovitosti je vˇcasih roˇcno testiranje boljˇsa izbira kot avtoma- tizacija. Za laˇzjo odloˇcitev lahko sledimo naslednjim kriterijem [9]:
• Robustnost: testni scenarij je nagnjen k ˇcloveˇskim napakam.
• Ponovljivost: testni scenarij se redno izvaja.
• Kritiˇcnost: testni scenarij pokriva kritiˇcne funkcije, ki bi v primeru nedelovanja povzroˇcile organizaciji veliko ˇskodo.
• Razliˇcni vhodni podatki: testni scenarij je treba ponoviti z velikim ˇstevilom razliˇcnih vhodnih podatkov.
• Casovna zahtevnost:ˇ roˇcno izvajanje testnega primera traja veliko ˇcasa.
Ce se naˇs testni scenarij ujema z veˇˇ c kot enim kriterijem, je avtomatizacija verjetno smiselna odloˇcitev, v nasprotnem primeru pa je treba premisliti, ali je vpeljava avtomatizacije zares stroˇskovno uˇcinkovita in izvedljiva.
Poglavje 3
Orodja in tehnologija
3.1 Selenium Webdriver
Selenium Webdriver ali skrajˇsano WebDriver je skupek streˇznika, ki de- luje kot vmesnik za upravljanje z brskalniki, in protokolov, ki omogoˇcajo komunikacijo med odjemalci in streˇznikom ter med streˇznikom in brskal- nikom. Streˇznik implementira mnoˇzico programskih vmesnikov (API), ki izvajajo razliˇcne interakcije na brskalnikih, kot so klik, vnaˇsanje besedila v polje in premikanje po strani [23]. Podatki med odjemalcem in streˇznikom se prenaˇsajo z uporabo protokola JSON wire, kar pomeni, da se podatki poˇsiljajo in sprejemajo v obliki JSON. Projekt je v letu 2018 uradno pri- poroˇcila organizacija W3C. Zaradi tega veˇcina sodobnih brskalnikov podpira, vzdrˇzuje in izboljˇsuje implementacijo protokola WebDriver, kar je poslediˇcno pripeljalo do bolj enotnih izvajanj interakcij na razliˇcnih brskalnikih [24].
3.2 Appium
Appium je odprtokodno ogrodje za avtomatizacijo testiranja domorodnih, hibridnih in mobilnih spletnih aplikacij [17]. Zasnovano je tako, da aplikacije ni treba na novo prevesti ali spreminjati, da bi jo lahko testirali, in tako, da ni omejeno na doloˇcen programski jezik. Lahko ga uporabimo v vsakem
7
jeziku, ki ima podporo za odjemalca HTTP [14].
3.2.1 Arhitektura
Appium je streˇznik HTTP, napisan v ogrodju Node.js, ki ustvarja in upravlja s sejami WebDriver. Zgrajen je na podlagi streˇznika Selenium Webdriver (razdelek 3.1), ki so ga nadgradili in prilagodili testiranju mobilnih aplikacij.
Zato tudi Appium sprejema zahteve v obliki JSON in z njimi upravlja na razliˇcne naˇcine glede na platformo. Streˇznik Appium pa ne more direktno poˇsiljati ukazov platformama iOs in Android, ampak je za to potreben ˇse dodaten gonilnik, ki sprejete ukaze na streˇzniku Appium prevede v ukaze, ki jih lahko doloˇcena platforma sprejme in izvede. Za platformo iOs se uporablja gonilnik XCUITest, za platformo Android pa UIAutomator2. Celoten tok od zahteve za doloˇceno interakcijo do povratne informacije o izvedeni zahtevi (slika 3.1) poteka po naslednjih korakih [11]:
1. Skripta, ki izvaja teste, s pomoˇcjo odjemalca Appium poˇslje zahtevo streˇzniku Appium preko protokola JSON wire.
2. Streˇznik Appium sprejme sporoˇcilo in poˇslje ukaz gonilniku za doloˇceno platformo.
3. Gonilnik ukaz prevede in ga poˇslje doloˇceni platformi.
4. Interakcija na napravi se bodisi izvede bodisi ne izvede.
5. Povratno informacijo o izvedbi interakcije sprejme gonilnik, ta pa pre- jeto sporoˇcilo nato prevede.
6. Streˇznik Appium posreduje rezultate testni skripti.
Diplomska naloga 9
Slika 3.1: Arhitektura orodja Appium
3.2.2 Gonilnik UIAutomator2
UIAutomator2 je gonilnik, ki ga streˇznik Appium uporablja, da izvaja ukaze na platformi Android. Gonilnik UIAutomator2 poˇsilja ukaze Googlovemu ogrodju UIAutomator, ki ponuja zbirko programskih vmesnikov za izvajanje interakcij na platformi Android [30].
3.2.3 Gonilnik XCUITest
XCUITest je gonilnik, ki ga streˇznik Appium uporablja za izvajanje ukazov na platformi iOs. Ta gonilnik dostopa do streˇznika po imenu WebDriverA- gent, ki teˇce kot domorodna aplikacija na testni napravi in podpira protokol WebDriver ter izpostavlja Applov programski vmesnik XCUITest API, preko katerega se izvajajo interakcije na platformi iOs [34].
3.2.4 Podprti programski jeziki
Ogrodje Appium se lahko uporablja v vsakem programskem jeziku, za ka- terega je izdelan odjemalec Appium. Moˇzno je narediti odjemalca za polju- ben programski jezik, saj je streˇznik Appium le streˇznik tipa REST API z znanimi dostopnimi toˇckami, vendar je priporoˇceno uporabljati ˇze obstojeˇce odjemalce, saj se tako zmanjˇsa moˇznost pojava napak. Trenutno obstajajo odjemalci za naslednje programske jezike [26]:
• Ruby
• Python
• Javascript
• Java
• PHP
• C#
• RobotFramework
3.2.5 Appium Desktop
Appium Desktop je program za platforme Windows, MacOS in Linux, ki omogoˇca zagon in konfiguracijo streˇznika Appium preko uporabniˇskega vme- snika (slika 3.2). Ponuja nam moˇznost shranjevanja razliˇcnih konfiguracij, ki jih lahko pri zagonu izberemo v zavihku Presets. Za pomoˇc pri razvoju in raz- hroˇsˇcevanju so po zagonu streˇznika na voljo sporoˇcila za beleˇzenje podatkov (angl. logs), ki jih izpisuje streˇznik, in tudi orodje Appium inspector (slika 3.3), ki nam omogoˇca pregled trenutne zgradbe uporabniˇskega vmesnika. S pomoˇcjo orodja Appium inspector lahko pridobimo identifikator ali XML-pot do ˇzelenega elementa, ki ju lahko v skripti uporabimo, da pridobimo element.
3.3 Pytest
Pytest je ogrodje za izdelavo testov v programskem jeziku Python. Lahko ga uporabimo za vse vrste testov in razliˇcne velikosti projekta, ki ga testiramo.
Je izredno prilagodljivo ogrodje, saj podpira dodajanje vtiˇcnikov (angl. plu- gins), ki so jih izdelali drugi razvijalci, omogoˇca funkcionalnost ponovnega zapisovanja preverjanja trditev (angl. assert rewriting), ki nam omogoˇca, da prilagodimo delovanje trditvenega stavka (angl. assert statement) naˇsim po- trebam, in ima razvijalcem prijazen napeljavni model (angl. fixture model), ki nam omogoˇca pripravo okolja za izvajanje testnih primerov [18].
Diplomska naloga 11
Slika 3.2: Zaˇcetna stran programa Appium Desktop
Slika 3.3: Appium Inspector
Teste, napisane v ogrodju Pytest, izvajamo preko ukazne vrstice z upo- rabo ukaza pytest. Ta v trenutnem imeniku samodejno poiˇsˇce teste, jih izvede in prikaˇze rezultate testiranja [18].
Metode, ki se izvedejo ob vzpostavitvi oziroma zakljuˇcku testnega scenarija
Pri ogrodju Pytest poznamo ˇstiri posebne metode:
1. Metoda setup class, ki se izvede ob inicializaciji razreda, ki vsebuje testne primere. Torej se izvede pred vsemi testnimi primeri.
2. Metoda teardown class, ki se izvede po zakljuˇcku vseh testnih pri- merov v razredu.
3. Metoda setup method, ki se izvede pred vsakim testnim primerom.
4. Metoda teardown method, ki se izvede po vsakem testnem primeru.
3.4 Naˇ crtovalski vzorec Page Object
Page object je naˇcrtovalski vzorec, ki temelji na tem, da se za vsako stran (angl. page) izdela razred, ki bo vseboval elemente te strani. S tem zmanjˇsamo ponavljanje iste kode, poveˇcamo vzdrˇzljivost testnih primerov in poveˇcamo berljivost same kode. V razredu BasePage (slika 3.4) se hranijo funkcije in atributi, ki so skupni vsem stranem. Ta razred sprejme objekt po imenu Driver, ki mu omogoˇca, da uporablja funkcije za pridobivanje elementov.
Vse ustvarjene strani podedujejo funkcije in atribute od razreda BasePage in implementirajo funkcije, ki so specifiˇcne za doloˇceno stran (npr. funkcije za pridobivanje elementov na strani). Testna skripta pridobi objekt strani z uporabo spremenljivke current page, kjer se hrani objekt trenutne strani.
Diplomska naloga 13
Slika 3.4: Naˇcrtovalski vzorec Page object
3.5 Espresso
Espresso je prilagodljivo ogrodje, ki hitro izvaja teste za preverjanje grafiˇcnega vmesnika aplikacij na platformi Android. Razvilo ga je podjetje Google in ga je objavilo kot odprtokodni projekt leta 2013 na Googlovi konferenci za avtomatizacijo testov. Danes je to najbolj priljubljeno ogrodje za testiranje aplikacij za platformo Android, saj ponuja razvijalcem veliko funkcionalnosti, ki jih nenehno izboljˇsujeta in nadgrajujeta podjetje Google in zdruˇzenje An- droid Open Source. Ogrodje Espresso podpira razliˇcice operacijskega sistema Android od 2.3.3 naprej in se izvaja preko mehanizma Android Instrumen- tation. Ta omogoˇca testnemu programu, da se izvaja na fiziˇcni napravi ali emulatorju na tak naˇcin, da testni program kliˇce programski vmesnik Instru- mentation API, ki mu omogoˇca izvajanje interakcij na napravi in pridobivanje konteksta aplikacije [36]. Zaenkrat sta edina podprta jezika Java in Kotlin.
3.6 ADB
ADB (Android debug bridge) je razvijalsko orodje za operacijski sistem An- droid, katerega namen je pridobivanje razhroˇsˇcevalskih podatkov od emu- latorja ali fiziˇcne naprave Android. Poleg tega omogoˇca tudi nalaganje in brisanje aplikacij ter dostop do Androidove lupine (angl. shell) za izvajanje sistemskih ukazov [28].
3.7 XCUITest
XCUItest je Applovo orodje za izvajanje testov uporabniˇskega vmesnika na platformi iOs. Temelji na ogrodju XCTest in zato podpira programska jezika Swift in Objective C, ki se uporabljata pri razvijanju aplikacij za sistem iOs [2]. Za pridobivanje podatkov o elementih uporabniˇskega vmesnika XCUI- Test uporablja Applov sistem Accessibility, ki osebam s posebnimi potrebami olajˇsuje uporabo Applovih naprav [31]. Tako se elementi, njihovi podatki in interakcije pridobivajo ter izvajajo s pomoˇcjo dostopnostnega identifikatorja
Diplomska naloga 15 (angl. accessibility identificator), ki ga razvijalci dodajo pri razvoju aplika- cije.
3.8 YAML
YAML (YAML Ain’t Markup Language) je serializacijski jezik, zasnovan tako, da je ˇcloveku prijazen, hkrati pa dobro deluje s sodobnimi program- skimi jeziki za potrebe vsakodnevnih nalog [19]. V zadnjih letih se mu je priljubljenost znatno poveˇcala in je zato pogosta izbira za konfiguracijske datoteke [35]. Ponuja preprost sistem za doloˇcanje tipov in podpira uporabo vzdevkov (angl. aliasing). Jezik YAML je tako dokaj enostaven za uporabo, obenem pa ponuja tudi kompleksnejˇse funkcionalnosti [10].
Poglavje 4
Implementacija
4.1 Opis implementacije
Z orodji in tehnologijami, opisanimi v poglavju 3, bomo izdelali reˇsitev, ki nam bo omogoˇcala, da z enim naborom kode testiramo aplikacije na platfor- mah iOs in Android.
Za izvajanje interakcij na mobilni napravi bomo uporabili streˇznik Appium in odjemalec Appium, za pisanje in izvajanje testov pa programski jezik Python skupaj z orodjem Pytest. Slika 4.1 opisuje arhitekturo naˇse apli- kacije. Vse se zaˇcne, ko s pomoˇcjo orodja Pytest zaˇzenemo testno skripto.
Testna skripta je podrazred razreda BaseCase (slika 4.1), ki skrbi za konfi- guracijo in inicializacijo odjemalca Appium, obenem pa vsebuje metode, ki so uporabne za veˇcino testnih primerov. Ker ˇzelimo, da je ogrodje ˇcimbolj prilagodljivo, beremo ˇzelene nastavitve, kot so na primer ime aplikacije, ki jo ˇzelimo testirati, in ime naprave, na kateri ˇzelimo, da se izvajajo testi, iz konfiguracijske datoteke. Za laˇzji razvoj in vzdrˇzljivost testov smo vpeljali naˇcrtovalski vzorec page object model, zato ima testna skripta na voljo spre- menljivko current page, v kateri se hrani objekt trenutne strani aplikacije.
V objektu strani so nam na voljo metode, ki uporabljajo objekt odjemalca Appium za dostop do elementov na trenutni strani aplikacije. Zaradi tega moramo objekt odjemalca Appium posredovati razredu strani. Interakcije na
17
mobilni napravi potekajo preko streˇznika Appium, s katerim komuniciramo preko odjemalca Appium, ki ga uporabljajo objekti strani. Testna skripta tako uporablja objekt strani, ki je shranjen v spremenljivki current page, za izvajanje interakcij na mobilni napravi.
Diplomska naloga 19
Slika 4.1: Arhitektura naˇse reˇsitve
4.2 Testi v orodju Pytest
V tem razdelku bomo pokazali, kako piˇsemo teste z uporabo orodja Pytest.
Vsak sklop testov bo zapisan v svoji datoteki in svojem razredu, vsak po- samezen test pa v svoji metodi. ˇCe si pogledamo primer testa, lahko hitro vidimo, kako preprosto je pisati testne primere.
d e f t e s t 0 1 ( s e l f ) :
u s e r n a m e i n p u t = s e l f . c u r r e n t p a g e . g e t u s e r n a m e i n p u t u s e r n a m e i n p u t ( ) . s e n d k e y s (” H e l l o w o r l d ! ”)
a s s e r t u s e r n a m e i n p u t ( ) . t e x t == ” H e l l o w o r l d ! ”, \
” Username s h o u l d be e q u a l t o H e l l o w o r l d ! ”
Izpis 4.1: Primer testa
Iz izpisa 4.1 lahko razberemo, da je test sestavljen iz dveh delov. V pr- vem delu izvedemo doloˇceno interakcijo ali pa pripravimo doloˇcene podatke.
V drugem delu nato s pomoˇcjo kljuˇcne besede assert preverimo, ali se je aplikacija odzvala tako, kot smo priˇcakovali. V izpisu 4.1 v vnosno polje za uporabniˇsko ime vnesemo besedilo “Hello world!” in preverimo, ˇce se je vre- dnost atributa text, ki pripada vnosnemu polju, zares spremenila v “Hello world!”. ˇCe se je vrednost pravilno spremenila, potem ta testni primer orodje Pytest oznaˇci kot uspeˇsno opravljen, sicer pa izpiˇse, da testni primer ni bil uspeˇsno opravljen, in doda sporoˇcilo “Username should be equal to Hello world!”.
V vsakem testnem primeru je dostopen objekt po imenu current page, v katerem so na voljo metode za dostopanje do elementov na trenutni strani aplikacije. V razdelku 4.5.3 si bomo ogledali moˇzne interakcije in atribute, ki jih lahko uporabimo.
4.2.1 Uporaba metod setup in teardown
Kot smo omenili v razdelku 3.3, obstajajo pri ogrodju Pytest ˇstiri posebne metode. Za nas je v tem razdelku predvsem pomembna metodasetup method,
Diplomska naloga 21 saj v njej doloˇcimo, na kateri strani se bodo izvajali testi. To naredimo z mnoˇzico pogojnih stavkov, ki preverjajo, na kateri strani se trenutno naha- jamo, in glede na to naloˇzijo zaˇzeleno stran ali pa stran, ki nas bo pripeljala do zaˇzelene strani.
d e f s e t u p m e t h o d ( s e l f , method ) :
i f s e l f . c u r r e n t p a g e . c l a s s . n a m e == ” I n i t i a l P a g e ”: s e l f . c u r r e n t p a g e . p r e s s l o g i n b u t t o n ( )
s e l f . l o a d p a g e (” l o g i n p a g e ”)
i f s e l f . c u r r e n t p a g e . c l a s s . n a m e == ” LoginPage ”: s e l f . c u r r e n t p a g e . l o g i n ( )
s e l f . l o a d p a g e (” home page ”)
Izpis 4.2: Primer navigacije do ˇzelene strani
Iz izpisa 4.2 vidimo, da s pomoˇcjo pogojnih stavkov preverimo, na kateri strani se trenutno nahajamo. Pomembno je, da si pogojni stavki sledijo v istem vrstnem redu kot strani v aplikaciji. Pogojni stavek, ki preveri, ˇce se nahajamo na strani za prijavo, bi torej moral biti zapisan pred pogojnim stavkom, ki preveri, ˇce se nahajamo na strani za urejanje profila. ˇCe v pogoj- nem stavku odkrijemo, da se nahajamo na doloˇceni strani, potem izvedemo korake, ki nas bodo peljali proti ˇzeleni strani. Iz izpisa 4.2 lahko vidimo, da ˇce se nahajamo na straniInitialPage, potem kliknemo na gumb login, ki nas pripelje do strani LoginPage. Na tej strani potem izvedemo potrebne korake za prijavo in to nas na koncu pripelje do strani HomePage, ki je naˇsa ˇzelena stran v tem primeru. Tako se sprehodimo skozi razliˇcne strani, dokler ne pridemo do ˇzelene strani. V metodi setup method se lahko izvajajo tudi druge funkcije, vendar bo navigacija skozi strani aplikacije prisotna skoraj pri vsakem sklopu testnih primerov.
Ker se aplikacija ne zaˇzene po vsakem testnem primeru, temveˇc samo po vsakem sklopu testnih primerov (vsakem razredu), moramo biti pozorni na to, da ima vsak testni primer na voljo enako stanje testne strani kot prvi testni primer. V ta namen uporabljamo metodo teardown method, v kateri vsa spremenjena stanja elementov vrnemo v prvotno stanje. Primer tega bi bilo testiranje strani za prijavo. ˇZeleli bi testirati razliˇcne vrednosti za
uporabniˇsko ime in geslo ter preveriti odziv aplikacije na te vrednosti. V metodi teardown method bi tako poskrbeli, da se vnosni polji za geslo in uporabniˇsko ime poˇcistita oz. vrneta v prvotno stanje po vsakem testnem primeru (izpis 4.3).
d e f teardown method ( s e l f , method ) :
s e l f . c u r r e n t p a g e . g e t u s e r n a m e i n p u t ( ) . c l e a r ( ) s e l f . c u r r e n t p a g e . g e t p a s s w o r d i n p u t ( ) . c l e a r ( )
Izpis 4.3: Primer ˇciˇsˇcenja vnosnih polj po testnih primerih
Ce bi ˇˇ zeleli v podatkovno bazo pred zaˇcetkom izvajanja testnih primerov dodati uporabnike ali pridobiti katere druge podatke, bi bili za to primerni metodi setup class in teardown class. V teh metodah bi pred zaˇcetkom vseh testnih primerov pridobili oz. vnesli podatke, na koncu pa bi se vneseni podatki po potrebi izbrisali.
4.3 Osnovni primer
Vsi testi, ki se bodo z naˇsim ogrodjem izvajali, imajo nekaj skupnih potreb.
Vsi potrebujejo zagnano aplikacijo oz. inicializirano sejo Appium in inicializi- rano spremenljivko current page, ki bi na zaˇcetku morala vsebovati objekt prve strani aplikacije. Da nam ne bi bilo vsakiˇc treba te logike pisati na novo, bodo vsi razredi, ki vsebujejo skupek testov, definirani kot podrazredi (dediˇci) razreda po imenu BaseCase, v katerem se nahaja vsa logika in vse metode, ki so potrebne ali pa uporabne za testiranje katerekoli aplikacije.
Razred BaseCaseimplementira metodosetup class, v kateri se iniciali- zirata seja Appium in spremenljivkacurrent page, v katero se shrani objekt prve strani aplikacije, preden se testi zaˇcnejo izvajati. Potrebne podatke za inicializacijo pridobi iz konfiguracijske datoteke (veˇc v razdelku 4.6).
Diplomska naloga 23
4.3.1 Inicializacija nove seje Appium
Za inicializacijo nove seje Appium moramo pridobiti primerek razreda po imenu WebDriver. Ta se uporablja kot gonilnik, s pomoˇcjo katerega ko- municirata testna skripta in streˇznik Appium. Da bi ga pravilno inicia- lizirali, mu podamo konfiguracijo iz konfiguracijske datoteke in preverimo, ˇce je bil ˇze inicializiran. ˇCe gonilnik ˇse ni inicializiran, pokliˇcemo funkcijo driver.load driver, sicer pa funkcijo driver.reload driver (izpis 4.4).
Situacija, ko je gonilnik ˇze inicializiran, lahko nastopi v primeru, ko hoˇcemo naenkrat zagnati veˇc sklopov testnih primerov (veˇc razredov, ki vsebujejo teste). Takrat se gonilnik inicializira ˇze pri prvem sklopu testnih primerov.
V tem primeru ˇzelimo samo ponovno zagnati aplikacijo, da bi se vsak sklop testov izvajal pod enakimi pogoji, zato pokliˇcemo metodo reload driver, ki ponovno zaˇzene aplikacijo. Lahko bi v obeh primerih klicali funkcijo load driver, vendar bi bilo to poˇcasneje, saj bi ta funkcija ponovno kre- irala sejo Appium in ˇsele potem ponovno zagnala aplikacijo [3].
d r i v e r = WebDriver ( c o n f i g=l o a d c o n f i g ( p y t e s t . c o n f i g p a t h ) ) i f d r i v e r . l o a d e d :
d r i v e r . r e l o a d d r i v e r ( ) e l s e:
d r i v e r . l o a d d r i v e r ( )
Izpis 4.4: Inicializacija gonilnika
4.3.2 Nalaganje objekta strani
RazredBaseCasevsebuje funkcijo za nalaganje objekta nove strani, ki ustvari objekt na podlagi razreda strani in ga shrani v spremenljivkocurrent page.
Metoda deluje tako, da ji podamo ime ˇzelenega razreda strani, ki je enako imenu datoteke, v kateri je shranjen razred strani (brez konˇcnice .py), potem pa s pomoˇcjo pythonove knjiˇznice importlib ustvari objekt na podlagi razreda strani in s klicem funkcije wait page poˇcaka, da se stran naloˇzi. ˇCe se stran uspeˇsno naloˇzi, potem se objekt strani zapiˇse v spremenljivkocurrent page.
4.3.3 Inicalizacija prve strani
Za vsako aplikacijo, ki jo ˇzelimo testirati z naˇsim ogrodjem, moramo izdelati razred, kamor zapiˇsemo vse metode, ki so skupne vsem stranem doloˇcene aplikacije. Temu razredu reˇcemo tudi osnovna stran aplikacije, saj se njegov primerek pri inicializaciji testnih primerov najprej ustvari. V tem razredu moramo zapisati ime razreda prve strani aplikacije (stran, ki se ob zagonu aplikacije po njeni namestitvi prva prikaˇze), da bi ga lahko naloˇzili pri ini- cializaciji testov. Pri inicializaciji razreda prve strani aplikacije najprej iz konfiguracijske datoteke preberemo ime aplikacije in s pomoˇcjo knjiˇznice im- portlib naloˇzimo primerek razreda osnovne strani aplikacije (izpis 4.5). Iz tega (razreda osnovne strani aplikacije) potem preberemo ime razreda prve strani aplikacije in ga naloˇzimo tako, kot je to opisano v razdelku 4.3.2.
app name = p y t e s t . app name
p a g e m o d u l e = i m p o r t m o d u l e ( f ’ c o r e . p a g e s .{app name}.{app name}’) a p p c l a s s = g e t a t t r( page module , g e t c l a s s n a m e ( app name ) )
a p p b a s e p a g e = a p p c l a s s ( )
r e t u r n s e l f . l o a d p a g e ( a p p b a s e p a g e . g e t f i r s t p a g e n a m e ( ) )
Izpis 4.5: Nalaganje instance prve strani aplikacije
4.4 Razredi strani
Razredi strani so kljuˇcnega pomena v naˇsem ogrodju. V vsakem tovrstnem razredu so zapisane metode za pridobivanje elementov na pripadajoˇci strani aplikacije. S tem si olajˇsamo razvoj, saj imamo vse elemente strani dosto- pne na enem mestu, in poenostavimo vzdrˇzevanje, saj je treba spremeniti samo dostop do elementa v razredu strani, ˇce se element ali njegov atribut spremenita.
Diplomska naloga 25
4.4.1 Osnovna stran
Razred osnovne strani (BasePage) je nadrazred vseh ostalih razredov strani, zato vsi drugi razredi strani od njega podedujejo vse metode in atribute.
V njem se nahajajo vse metode in atributi, ki so skupni ali uporabni za vse razrede, ki implementirajo metode in atribute za doloˇceno stran. Pri inicializaciji vsakega razreda strani se razredu BasePage posreduje primerek gonilnika (veˇc v razdelku 4.5), ki ga razredi strani uporabljajo za dostop do elementov. V testnih primerih pogosto uporabljamo metode iz razreda BasePage, kot so:
• is element visible, ki preveri, ali je podani element trenutno viden;
• is element usable, ki preveri, ali lahko dostopamo do podanega ele- menta;
• clear input, ki poˇcisti besedilo v podanem vnosnem polju;
• is checked, ki preveri, ali podani element vsebuje atribut checked in ali je nastavljen na vrednosttrue, kar je uporabno pri razliˇcnih gumbih;
• scroll page, ki pomakne stran navzgor ali navzdol.
Poleg naˇstetih je pomembno izpostaviti ˇse metodo wait page. V tej me- todi povemo, ali se je naˇsa stran dokonˇcno naloˇzila in koliko ˇcasa ˇzelimo ˇcakati, da se stran naloˇzi. Zato se od vseh razredov strani priˇcakuje, da im- plementirajo svojo razliˇcico te metode in s tem definirajo, kdaj se je njihova stran dokonˇcno naloˇzila. To je zelo pomembno, saj v testnih primerih ne ˇzelimo dostopati do elementov, preden se stran naloˇzi do konca. Preverjanje dokonˇcnega nalaganja strani ponavadi izvedemo tako, da poskusimo prido- biti element, za katerega vemo, da ˇce ga bomo uspeˇsno pridobili, bomo lahko pridobili tudi druge elemente na strani (izpis 4.6). Poleg tega je smiselno po- dati parameterwait, s katerim povemo, koliko ˇcasa ˇzelimo poˇcakati, preden vrnemo podatek, da elementa ni bilo moˇzno pridobiti.
d e f w a i t p a g e ( s e l f , w a i t =20) :
r e t u r n s e l f . g e t l o g i n b u t t o n ( w a i t )
Izpis 4.6: Primer implementacije metode wait page
4.4.2 Osnovna stran aplikacije
Kot smo omenili v razdelku 4.3.3, moramo za vsako aplikacijo izdelati ra- zred za osnovno stran aplikacije kot podrazred razreda BasePage, v katerem podamo ime datoteke, ki vsebuje razred prve strani aplikacije (izpis 4.7).
Poleg tega lahko v ta razred dodamo tudi vse ostale atribute in metode, ki so skupne vsem stranem za doloˇceno aplikacijo.
d e f g e t f i r s t p a g e n a m e ( s e l f ) : r e t u r n ” l o g i n p a g e ”
Izpis 4.7: Ime datoteke, ki vsebuje razred prve strani aplikacije
4.4.3 Dostop do elementov
Ko testiramo z orodjem Appium, imamo veˇc naˇcinov za iskanje elementov.
Naslednji naˇcini se lahko uporabljajo na vseh platformah [22]:
• Accessibility ID: Elemente iˇsˇcemo z uporabo unikatnega identifika- torja (izpis 4.8). Pri platformi iOs se identifikator zapiˇse kot niz v polje accessibility-id, katerega namen je ta, da skriptam za testi- ranje uporabniˇskega vmesnika olajˇsa iskanje in dostop do elementov.
Poslediˇcno se pri platformi iOs preteˇzno uporablja ta naˇcin iskanja [1].
Na platformi Android se pri tem naˇcinu iskanja iˇsˇce identifikator znotraj poljacontent-desc, katerega namen je ta, da opiˇse vsebino doloˇcenega elementa in s tem olajˇsa uporabo mobilne naprave osebam s posebnimi potrebami. Poljecontent-descponavadi vsebuje presledke in ni nujno unikatno, zato se pri platformi Android ta naˇcin iskanja ponavadi ne uporablja.
Diplomska naloga 27
driver.find elements by accessibility id(’SomeAccessibilityID’)
Izpis 4.8: Primer iskanja z uporabo Accessibility ID
• Ime razreda: Elemente iˇsˇcemo z uporabo imena njihovega razreda (izpis 4.9). Pri platformi Android je to kar polno ime razreda (npr.
android.view.TextView), pri platformi iOs pa polno ime elementa, ki se zaˇcne z nizom XCUIElementType. Ta naˇcin iskanja je uporaben, kadar ˇzelimo pridobiti veˇc elementov istega tipa (npr. vse slike na strani).
d r i v e r . f i n d e l e m e n t s b y c l a s s n a m e (” some . c l a s s . name”)
Izpis 4.9: Primer iskanja z uporabo imena razreda
• Domorodni identifikator elementa: Element iˇsˇcemo z uporabo do- morodnega identifikatorja elementa (izpis 4.10), ki se kot niz zapiˇse v polje name pri platformi iOs in v polje resource-id pri platformi Android. To je najpogosteje uporabljeni naˇcin iskanja pri platformi Android, saj se polje resource-id skoraj vedno uporablja ˇze pri ra- zvoju aplikacij za to platformo.
d r i v e r . f i n d e l e m e n t s b y i d (’ s o m e i d ’)
Izpis 4.10: Primer iskanja z uporabo domorodnega identifikatorja
• Ime elementa: Elemente iˇsˇcemo z uporabo atributaname(izpis 4.11).
Ta naˇcin iskanja uporabljajo predvsem hibridne ali spletne aplikacije, ki imajo definiran atributname. Pri platformi iOs ta naˇcin iskanja sicer lahko uporabljamo, vendar je bolje, ˇce uporabljamo domorodni identi- fikator elementa, saj ga v nekaterih primerih lahko ponovno uporabimo pri platformi Android. Pri platformi Android polje name ponavadi ni definirano v atributih elementa, zato se ta naˇcin iskanja obiˇcajno ne uporablja.
d r i v e r . f i n d e l e m e n t s b y n a m e (’ some name ’)
Izpis 4.11: Primer iskanja z uporabo imena elementa
• XPath: Elemente iˇsˇcemo z uporabo poizvedovalnega jezika XPath (iz- pis 4.12). To je najrobustnejˇsi naˇcin iskanja po dokumentih XML.
Pogosto se uporablja pri seznamih elementov, saj lahko iˇsˇcemo element po indeksu in razredu hkrati. ˇCeprav je ta naˇcin najrobustnejˇsi, je tudi najpoˇcasnejˇsi, zato se mu poskuˇsamo izogniti.
d r i v e r . f i n d e l e m e n t s b y x p a t h (
’ // a n d r o i d . w i d g e t . TextView [ @text=” H e l l o World ” ] ’)
Izpis 4.12: Primer iskanja z uporabo poizvedovalnega jezika XPath
• Slika: Slike iˇsˇcemo z uporabo poizvedbene slike, zakodirane v formatu base64.
4.4.4 Implementacija razreda strani
Ce ˇˇ zelimo testirati doloˇceno stran aplikacije, moramo izdelati tri nove razrede.
Po en razred potrebujemo za vsako platformo, saj ˇzelimo imeti loˇcene metode za pridobivanje elementov za platformi iOs in Android. Tretji razred bo uporabljen kot generiˇcni razred, ki bo vseboval metode in atribute, ki si jih delita obe platformi.
Najprej izdelamo generiˇcni razred kot podrazred razreda osnovne strani aplikacije (BasePage) in v njem implementiramo metodo wait page (izpis 4.13). V tej metodi vrnemo logiˇcno resnico, ko se stran dokonˇcno naloˇzi (ˇce se to zgodi v podanem ˇcasovnem obdobju).
Diplomska naloga 29
c l a s s LoginPage ( BasePage ) :
d e f w a i t p a g e ( s e l f ) :
r e t u r n s e l f . g e t u s e r n a m e i n p u t ( w a i t =20)
Izpis 4.13: Primer generiˇcne strani za prijavo
Ko je generiˇcni razred izdelan, lahko implementiramo razreda strani za platformi Android in iOs (izpisa 4.14 in 4.15). Oba razreda strani podedu- jeta metode in atribute od omenjenega generiˇcnega razreda in implementirata metode za dostop do elementov. Pri pisanju imen metod pazimo, da imajo metode, ki pridobivajo iste elemente, tudi ista imena. S tem si olajˇsamo razvoj testnih primerov, ker nam ni treba preverjati, na kateri platformi iz- vajamo teste. ˇCe sta strani identiˇcni na obeh platformah, je edina razlika v njunih razredih samo naˇcin dostopanja do elementov. Kot smo povedali v razdelku 4.4.3, se pri platformi Android najpogosteje uporablja iskanje z domorodnim identifikatorjem elementa, pri platformi iOs pa iskanje z dosto- pnostnim identifikatorjem.
classLoginPage(GenericLoginPage):
defget username input(self,∗∗kwargs):
returnself.driver.find element by id(’username input’,∗∗kwargs)
defget password input(self,∗∗kwargs):
returnself.driver.find element by id(’password input’,∗∗kwargs)
defget login button(self, ∗∗kwargs):
returnself.driver.find element by id(’login button’,∗∗kwargs)
Izpis 4.14: Primer implementacije razreda strani za platformo Android
c l a s s LoginPage ( G e n e r i c L o g i n P a g e ) :
d e f g e t u s e r n a m e i n p u t ( s e l f , ∗∗kwargs ) :
r e t u r n s e l f . d r i v e r . f i n d e l e m e n t b y a c c e s s i b i l i t y i d (
’ u s e r n a m e i n p u t ’,
∗∗kwargs )
d e f g e t p a s s w o r d i n p u t ( s e l f , ∗∗kwargs ) :
r e t u r n s e l f . d r i v e r . f i n d e l e m e n t b y a c c e s s i b i l i t y i d (
’ p a s s w o r d i n p u t ’,
∗∗kwargs )
d e f g e t l o g i n b u t t o n ( s e l f , ∗∗kwargs ) :
r e t u r n s e l f . d r i v e r . f i n d e l e m e n t b y a c c e s s i b i l i t y i d (
’ l o g i n b u t t o n ’,
∗∗kwargs )
Izpis 4.15: Primer implementacije razreda strani za platformo iOs
4.5 Odjemalec Appium
Naˇse ogrodje uporablja orodje Appium, da bi izvajalo interakcije na mobilnih napravah. Kot smo omenili v razdelku 3.2.1, je Appium le streˇznik HTTP, zato je potreben tudi odjemalec HTTP, ki nam bo omogoˇcil komunikacijo s streˇznikom. Za programski jezik Python obstaja odjemalec Appium [6], ki ga lahko naloˇzimo s pomoˇcjo orodja Pip. Da bi ga zaˇceli uporabljati, moramo iz odjemalca Appium uvoziti razredwebdriver, ki nam nudi metode za komunikacijo z streˇznikom Appium.
Diplomska naloga 31
4.5.1 Zelene zmogljivosti ˇ
Za zaˇcetek nove seje moramo streˇzniku Appium povedati, kako ˇzelimo izvajati naˇse teste. To storimo tako, da zgradimo slovar ˇzelenih zmogljivosti (angl.
desired capabilities), ki jo odjemalec Appium poˇslje streˇzniku Appium kot objekt JSON. Obstaja veliko razliˇcnih nastavitev, s katerimi opiˇsemo, na kakˇsen naˇcin in v kakˇsnem okolju ˇzelimo, da se naˇsi testi izvajajo. ˇCeprav obstaja veliko razliˇcnih nastavitev, naˇse ogrodje uporablja le najbolj osnovne, ki so potrebne za zagon testnih primerov na obeh platformah [4]:
• Nastavitev platformName, kjer povemo, katero platformo ˇzelimo te- stirati (iOS, Android).
• Nastavitev deviceName, kjer podamo ime naprave, na kateri ˇzelimo izvajati teste. Pomembno je, da se ime ujema z imenom, ki ga naprava sporoˇci raˇcunalniku.
• Nastavitev automationName, kjer povemo, kateri gonilnik ˇzelimo uporabiti.
• Nastavitevapp, kjer podamo absolutno pot ali naslov URL aplikacije, ki jo ˇzelimo testirati. Pri platformi Android je to absolutna pot do datoteke s konˇcnico .apk, medtem ko je pri platformi iOs to absolutna pot do datoteke s konˇcnico .app ali .ipa.
Poleg omenjenih bi izpostavili ˇse nekaj pogosto uporabljenih nastavi- tev pri testiranju mobilnih aplikacij, ki sicer niso implementirane v naˇsem ogrodju, vendar se jih lahko z malo truda hitro doda [4]:
• NastavitevplatformVersion, kjer podamo razliˇcico platforme, na ka- teri ˇzelimo, da se testi izvajajo.
• Nastavitevlanguage, kjer povemo, kateri jezik naj testirana aplikacija uporablja.
• Nastavitevorientation, kjer povemo, ali ˇzelimo, da je naprava v vodo- ravni ali navpiˇcni orientaciji pri izvajanju testov (to lahko uporabimo le pri simulatorjih).
• Nastavitev otherApps, kjer naˇstejemo poti do vseh ostalih aplikacij, katere ˇzelimo namestiti, preden se testirana aplikacija zaˇzene.
.
4.5.2 Razred Webdriver
Da bi lahko funkcionalnosti razreda webdriver nadgradili, smo izdelali naˇs lasten razred z istim imenom. Razred smo definirali kot podrazred razreda webdriveriz knjiˇznice python-appium in v njem implementirali nove metode ter nadgradili nekatere ˇze obstojeˇce metode. Poleg tega smo pri naˇsem ovoj- nem razredu uporabili vzorec enojˇcek (angl. singleton), kar pomeni, da vsi ostali razredi uporabljajo isti primerek naˇsega razreda, s ˇcimer se izognemo morebitnim ponovnim ustvarjanjem sej ali nalaganjem aplikacij.
Inicializacija seje
Za kreiranje nove seje Appium moramo definirati ˇzelene zmogljivosti in URL- naslov naslov streˇznika Appium. ˇZelene zmogljivosti pridobimo iz konfigu- racijske datoteke in jih prepiˇsemo v slovar. URL-naslov streˇznika Appium preberemo iz programa Appium desktop in ga zapiˇsemo v naˇsem razredu webdriver. Slovar ˇzelenih zmogljivosti in URL-naslov streˇznika vstavimo v konstruktor naˇsega razreda webdriver in s tem ustvarimo novo sejo.
Metode za pridobivanje elementov
Metode za pridobivanje elementov v poglavju 4.4.3 smo v naˇsem razredu webdrivernadgradili tako, da smo vsaki metodi dodali parameterwait, s ka- terim povemo, kako dolgo ˇzelimo ˇcakati na element, preden dobimo sporoˇcilo, da element ni bil najden. To naredimo s klicem funkcije implicitly wait,
Diplomska naloga 33 ki pove odjemalcu Appium, da poskuˇsa pridobiti element, dokler ga ne najde ali pa poteˇce podani ˇcas [13]. Kot privzeto smo nastavili, da pri iskanju ele- menta poˇcakamo najveˇc pet sekund. S tem se izognemo teˇzavam, ko se vsi elementi na strani ne naloˇzijo takoj in moramo na nekatere poˇcakati.
4.5.3 Interakcije z elementi
Interakcija z elementi je kljuˇcna funkcionalnost, brez katere ne bi mogli iz- vajati testov na mobilnih napravah. Za pridobivanje informacij o trenutnem stanju elementa uporabljamo metode, ki pridobijo atribute elementa iz tre- nutne postavitve strani (angl. layout), zapisane v obliki XML. Odjemalec Appium nam ponuja mnoˇzico funkcij za izvajanje najbolj pogosto uporablje- nih akcij nad elementi.
Pridobivanje atributov elementa
Za pridobivanje atributov elementa uporabljamo naslednje metode:
• Metoda text pridobi vidno besedilo elementa.
• Metoda name pridobi ime znaˇcke predmeta.
• Metoda get attribute pridobi vrednost podanega atributa. S to metodo bi lahko zapisali tudi vse ostale metode (npr. text bi prevedli v get attribute(”text”)).
• Metoda is selected nam pove, ali je element izbran.
• Metoda is enabled nam pove, ali je element omogoˇcen.
• Metoda is displayed nam pove, ali je element trenutno prikazan.
• Metoda location vrne koordinate elementa.
• Metoda size vrne viˇsino in ˇsirino elementa.
• Metoda rect vrne koordinate ter viˇsino in ˇsirino elementa v enem objektu.
Izvajanje akcij nad elementi
Za najbolj preproste akcije (klik na sredino elementa, vnos ˇcrk v vnosno po- lje in brisanje polja) ima odjemalec Appium ˇze definirane funkcije click, send keys in clear. Kompleksnejˇse akcije pa izvajamo s pomoˇcjo objekta TouchAction. Objekt TouchAction lahko hrani verigo dogodkov, ki jih ˇzelimo izvesti [29]. Simulacijo premikanja prsta od enega elementa do dru- gega bi zapisali na naˇcin, prikazan v izpisu 4.16.
TouchAction ( ) . p r e s s ( e l e m e n t 1 ) . moveTo ( e l e m e n t 2 ) . r e l e a s e ( )
Izpis 4.16: Primer verige dogodkov
Od dogodkov imamo na voljopritisni (angl. press), spusti (angl. release), premakni se do (angl. move to), dotakni se (angl. touch), poˇcakaj (angl.
wait), dolgi pritisk (angl. long press), prekliˇci (angl. cancel) in izvedi (angl.
perform) [29]. S temi ukazi lahko simuliramo veˇcino dogodkov, ki bi jih uporabnik izvajal na svoji mobilni napravi.
4.6 Konfiguracija
Da bi naˇse ogrodje vedelo, katero aplikacijo ˇzelimo testirati in na kateri plat- formi bi to radi poˇceli, moramo te podatke zapisati v konfiguracijsko da- toteko. Konfiguracijsko datoteko bomo pisali v jeziku YAML, brali pa s pomoˇcjo pythonove knjiˇznice PyYaml [21]. Naslednji podatki morajo biti nujno prisotni v konfiguracijski datoteki:
• Ime platforme, ki je lahko bodisi Android ali pa iOs.
• Ime naprave, na kateri ˇzelimo izvajati teste. Pomembno je, da se ime ujema z imenom, ki ga naprava sporoˇci raˇcunalniku.
• Ime aplikacije, ki ga ogrodje uporabi za pridobivanje strani.
• Ime gonilnika Appium, ki ga ˇzelimo uporabljati. Ponavadi je to go- nilnik XCUITest za platformo iOs in gonilnik UIAutomator2 za plat- formo Android.
Diplomska naloga 35
• Pot do aplikacijske datoteke, ki mora biti absolutna in v primeru platforme Android kaˇze na datoteko s konˇcnico .apk, v primeru plat- forme iOs pa na datoteko s konˇcnico .app.
Pri zagonu testnih primerov moramo povedati, katero konfiguracijo bi ˇzeleli uporabljati. To storimo tako, da v ukazni vrstici dodamo argument --configin za tem zapiˇsemo ime naˇse konfiguracijske datoteke brez konˇcnice (npr. --config appium android). Orodje Pytest nam omogoˇca, da to vre- dnost preberemo in jo kasneje posredujemo razreduBaseCase, kjer se potem konfiguracijska datoteka tudi naloˇzi.
4.7 Datoteˇ cna struktura
V tem poglavju si bomo ogledali datoteˇcno strukturo naˇsega ogrodja in poja- snili, kam moramo dodati datoteke, da bi lahko uporabili ogrodje za testiranje aplikacij.
/
configs
appium android.yaml core
pages app name
android generic ios
base page.py base case.py util.py webdriver.py tests
app name my test.py conftest.py
Slika 4.2: Datoteˇcna struktura
Na sliki 4.2 je prikazana datoteˇcna struktura, ki vsebuje eno aplikacijo (imenuje se app name). Da bi ogrodje delovalo, je izredno pomembno, da se drˇzimo naslednjih pravil pri dodajanju novih datotek:
• V imenik configs dodamo konfiguracijsko datoteko, ki smo jo obrav- navali v razdelku 4.6.
• Za vsako aplikacijo moramo izdelati imenik znotraj imenikacore/pages.
V imeniku, ki pripada aplikaciji, ustvarimo datoteko z razredom za osnovno stran aplikacije in tri podimenike (android, generic in ios), kjer se bodo hranili razredi strani.
• Novi testne primere dodamo v imenik tests, saj je to imenik, kjer orodje Pytest iˇsˇce testne primere [20]. Dodajanje testov v poseben po- dimenik znotraj imenikatestsni nujno, je pa priporoˇcljivo v primeru, da hranimo teste za veˇc razliˇcnih aplikacij.
• Vsaka datoteka, ki bo vsebovala teste, mora v svojem imenu vsebovati besedo test, saj je orodje Pytest sicer ne bo zaznalo kot datoteko s testnimi primeri [20].
Poglavje 5
Primerjava orodij
V tem poglavju bomo s primerjavo naˇsega ogrodja z domorodnimi ogrodji za platformi Android in iOs prikazali njegove glavne prednosti in pomanj- kljivosti. Definirali bomo devet testnih primerov, ki jih bomo avtomatizirali z naˇsim ogrodjem, ogrodjem Espresso za platformo Android in ogrodjem XCUItest za platformo iOs. Ogrodja bomo med seboj primerjali po naˇcinu implementacije, hitrosti in zanesljivosti.
5.1 Testna aplikacija
Testne primere bomo definirali na podlagi aplikacije, ki jo bomo izdelali tako, da bomo vanjo vkljuˇcili elemente, ki se v sodobnih aplikacijah pogosto upora- bljajo. Aplikacija bo obsegala dve strani. Prva bo simulirala prijavno stran, kjer se bo mogoˇce prijaviti z vnosom uporabniˇskega imena in gesla (slika 5.1). Glede na uspeˇsnost prijave se nam bo bodisi odprla druga stran aplika- cije bodisi prikazalo sporoˇcilo o neuspeˇsni prijavi. Na drugi strani aplikacije bodo za testiranje na voljo razliˇcni pogosto uporabljeni elementi, kot so dr- snik (angl. slider), stikalo (angl. switch), izbirna tipka (angl. radio button), gumb, potrditveno polje (angl. checkbox), vnosno polje za komentarje (angl.
comment box) in polje za prikazovanje komentarjev (slika 5.2).
37
Slika 5.1: Prva stran aplikacije na platformi Android
Diplomska naloga 39
Slika 5.2: Druga stran aplikacije na platformi Android
5.1.1 Streˇ znik za prijavo
Ker ˇzelimo simulirati delovanje prave aplikacije, bomo pri izdelavi aplika- cije uporabili preprost streˇznik s programskim vmesnikom REST. Ta nam bo omogoˇcal, da poˇsljemo zahtevo za prijavo, poˇcakamo na odgovor in se odzovemo glede na vsebino odgovora. Logika na streˇzniku bo preprosta:
• Ob zahtevi POST na poti /login bo odgovoril s sporoˇcilom OK, ˇce bosta uporabniˇsko ime in geslo enaka besedam Andrija inDiploma.
• Ob zahtevi POST na poti/loginbo odgovoril s sporoˇcilomINCORRECT CREDENTIALS, ˇce se geslo in uporabniˇsko ime ne bosta ujemala z nave- denima besedama.
Na ta naˇcin bomo lahko pokazali, kako v razliˇcnih ogrodjih poˇcakamo, da se doloˇcen element prikaˇze.
5.2 Testni primeri
Testne primere bomo razdelili na dva dela. Prvi del bo pokrival teste, ki se izvajajo na strani za prijavo, drugi del pa teste, ki se izvajajo na drugi strani aplikacije.
5.2.1 Testni primeri strani za prijavo
1. V vnosno polje za uporabniˇsko ime vnesi besedilo Hello world in pre- veri, ˇce se je besedilo v vnosnem polju prikazalo.
2. Test za prijavo z napaˇcnim geslom: v polje za uporabniˇsko ime vnesi Andrija, v polje za geslo pa vnesi nepravilno ter klikni na gumb login. Prepriˇcaj se, da se je pojavno okno (angl. popup window) prikazalo. ˇCe klikneˇs gumb try again, se pojavno okno zapre in je znova na voljo prva stran za prijavo.
Diplomska naloga 41 3. Test za prijavo s pravilnim uporabniˇskim imenom in geslom: v polje za uporabniˇsko ime vnesi Andrija, v polje za geslo pa vnesi Diploma ter klikni na gumb login. Prepriˇcaj se, da se je prikazala druga stran aplikacije.
5.2.2 Testni primeri za drugo stran
V tem sklopu bomo definirali teste, ki bodo preverili delovanje elementov na drugi strani aplikacije. Predpogoj za vse teste v tem sklopu je, da je druga stran odprta, preden se testi zaˇcnejo izvajati.
1. Test za stikalo: klikni na stikalo in se prepriˇcaj, da se je vrednost stikala spremenila.
2. Test za potrditvena polja: klikni na vsako potrditveno polje in se pre- priˇcaj, da se je vrednost vsakega potrditvenega polja spremenila.
3. Test za izbirne tipke: klikni na prvo izbirno tipko in se prepriˇcaj, da se je vrednost tipke spremenila. Potem klikni na drugo izbirno tipko in se prepriˇcaj, da je to edina tipka, ki je oznaˇcena.
4. Test za vnosno polje: v vnosno polje za komentarje vnesi This is an example of a comment in se prepriˇcaj, da se je vrednost vnosnega polja spremenila v prej omenjeni komentar.
5. Test za komentarje: v vnosno polje za komentarje vnesi First post textin klikni na gumb post. Prepriˇcaj se, da se je komentar prikazal v polju za izpis komentarjev pod vnosnim poljem za komentarje.
6. Test za drsnik: premakni drsnik toˇcno do polovice in se prepriˇcaj, da se je vrednost drsnika spremenila na 50% oz. 0.5.
5.3 Pridobivanje elementov
V tem poglavju bomo primerjali, kako pridobivamo elemente z ogrodjema Epsresso in XCUITest ter z naˇsim ogrodjem.
// P r i d o b i v a n j e e l e m e n t a z uporabo i d e n t i f i k a t o r j a e l e m e n t a onView ( w i t h I d (R . i d . u s e r n a m e i n p u t ) )
Izpis 5.1: Pridobivanje elementa z ogrodjem Espresso
// P r i d o b i v a n j e e l e m e n t a z uporabo a c c e s s i b i l i t y i d e n t i f i k a t o r j a app . t e x t F i e l d s [” u s e r n a m e i n p u t ”]
Izpis 5.2: Pridobivanje elementa z ogrodjem XCUITest
# P r i d o b i v a n j e e l e m e n t a z uporabo i d e n t i f i k a t o r j a e l e m e n t a d r i v e r . f i n d e l e m e n t b y i d (’ u s e r n a m e i n p u t ’)
# P r i d o b i v a n j e e l e m e n t a z uporabo a c c e s s i b i l i t y i d e n t i f i k a t o r j a d r i v e r . f i n d e l e m e n t b y a c c e s s i b i l i t y i d (’ u s e r n a m e i n p u t ’)
Izpis 5.3: Pridobivanje elementa z uporabo odjemalca Appium
Pri ogrodju Espresso uporabljamo objekte po imenu viewMatcher. To so objekti, s katerimi funkciji onView povemo, kakˇsne elemente ˇzelimo pri- dobiti. Vsak objekt viewMatcher je vezan na doloˇcen tip ali pa na doloˇcen atribut elementa [32]. V izpisu 5.1 smo uporabili pogledni ujemalnik (angl.
view matcher) withId, ki je vezan na atribut id elementa, kar pomeni, da ˇzelimo pridobiti vse elemente s podano vrednostjo atributa id. Ta pogle- dni ujemalnik se pogosto uporablja, obstaja pa ˇse veˇc kot 50 drugih pogle- dnih ujemalnikov, s katerimi lahko natanˇcno opiˇsemo ˇzelene elemente (npr.
withText,withContentDescription,isFocusable...) [8].
Pri ogrodju XCUITest uporabljamo objekt XCUIElementQuery, s kate- rim opiˇsemo, kakˇsen element iˇsˇcemo. Za razliko od ogrodja Espresso mo- ramo pri Applovem ogrodju povedati, kakˇsen tip elementa ˇzelimo pridobiti in ˇsele nato podati dostopnostni identifikator ˇzelenega elementa. To je pri- kazano v izpisu 5.2, kjer ˇzelimo pridobiti vnosno polje za uporabniˇsko ime,
Diplomska naloga 43 toda preden podamo identifikator, moramo povedati, da iˇsˇcemo element tipa textField (XCTextField). Z uporabo naslednjih metod lahko tvorimo tudi kompleksnejˇse poizvedovalne stavke za iskanje:
• children, ki vrne vse otroke podanega elementa;
• descendants, ki vrne vse naslednike podanega elementa;
• contains, ki vrne vse elemente, ki vsebujejo naslednike, opisane s po- danim predikatom;
• matches, ki vrne vse elemente, ki ustrezajo danemu predikatu.
Pri naˇsem ogrodju lahko pridobivamo elemente na naˇcine, opisane v raz- delku 4.4.3. Od teh se najpogosteje uporabljata naˇcin z uporabo dostopno- stnega identifikatorja in naˇcin z uporabo domorodnega identifikatorja ele- menta (izpis 5.3). ˇCe ˇzelimo ustvariti kompleksnejˇsi poizvedovalni stavek, uporabimo naˇcin, kjer iˇsˇcemo elemente z uporabo poizvedovalnega jezika XPath.
5.4 Interakcije z elementi
V tem razdelku bomo primerjali, kako na razliˇcnih ogrodjih izvajamo inte- rakcije z elementi.
5.4.1 Izvajanje akcij
// I z v a j a n j e a k c i j e d o t i k a myElement . p e r f o r m ( c l i c k ( ) )
// I z v a j a n j e a k c i j e vnosa b e s e d i l a v vnosno p o l j e myInputElement . p e r f o r m ( t yp e T e x t (”Some t e x t ”) )
Izpis 5.4: Izvajanje akcij na elementu z ogrodjem Espresso
// I z v a j a n j e a k c i j e d o t i k a myElement . t ap ( )
// I z v a j a n j e a k c i j e vnosa b e s e d i l a v vnosno p o l j e myInputElement . t y pe T e x t (”Some t e x t ”)
Izpis 5.5: Izvajanje akcij na elementu z ogrodjem XCUITest”
# I z v a j a n j e a k c i j e d o t i k a myElement . t ap ( )
# P r i d o b i v a n j e e l e m e n t a z uporabo a c c e s s i b i l i t y i d e n t i f i k a t o r j a myInputElement . s e n d k e y s (”Some t e x t ”)
Izpis 5.6: Izvajanje akcij na elementu z uporabo odjemalca Appium Ogrodje Espresso za izvajanje akcij uporablja metode
’ ki vraˇcajo objekt tipa ViewAction, ki definira, kakˇsna akcija naj se izvede na elementu. Te metode vstavljamo v funkcijoperform(izpis 5.4), ki lahko izvede eno ali veˇc podanih metod, in tako tvorimo kompleksnejˇse akcije nad elementom. Poleg tega lahko definiramo tudi lastne razrede, ki razˇsirjajo razred ViewAction.
To moˇznost smo uporabili, da pri testih z ogrodjem Espresso definiramo funkcijo waitForElement, ki poˇcaka podano ˇstevilo milisekund, da se ele- ment prikaˇze.
Pri ogrodju XCUITest so akcije definirane kot metode elementa, kar je razvidno iz izpisa 5.5. Za razliko od ogrodja Espresso ni mogoˇce dodati svojih metod, moˇzno pa je izdelati ovojnico okoli razreda XCUIElement in uporabiti obstojeˇce metode za definicijo novih. Prav tako se nam do elementa ni treba drsno premikati (angl. scrolling), temveˇc se drsno pomikanje izvede ˇze pri pridobivanju elementa. ˇCe torej element obstaja, potem ogrodje stran samodejno drsno premika, dokler element ni viden.
Pri naˇsem ogrodju so za najosnovnejˇse akcije definirane metode v objektu elementa (izpis 5.6), tako kot to velja za ogrodje XCUITest. Za kompleksnejˇse akcije, kot je na primer drsno premikanje (angl. scrolling) ali pa vleˇcenje s pr- stom (angl. swiping), pa uporabljamo objekteTouchAction, ki so podrobneje
Diplomska naloga 45 opisani v razdelku 4.5.3.
Pridobivanje vrednosti atributov
V tem poglavju bomo primerjali, kako pridobimo atribute elementa z uporabo razliˇcnih ogrodij.
// P r i d o b i v a n j e v r e d n o s t i a t r i b u t a t e x t g e t T e x t ( myElement )
Izpis 5.7: Pridobivanje atributov elementa z ogrodjem Espresso
// P r i d o b i v a n j e v r e d n o s t i e l e m e n t a myElement . v a l u e
Izpis 5.8: Pridobivanje atributov elementa z ogrodjem XCUITest”
# P r i d o b i v a n j e v r e d n o s t i a t r i b u t a t e x t myElement . t e x t
# P r i d o b i v a n j e a t r i b u t a z imenom ” a t t r i b u t e n a m e ” myElement . g e t a t t r i b u t e (” a t t r i b u t e n a m e ”)
Izpis 5.9: Pridobivanje atributov elementa z uporabo odjemalca Appium Iz izpisa 5.9 vidimo, da lahko pri naˇsem ogrodju zelo preprosto pridobimo atribute elementov. Za najpogostejˇse atribute imamo na voljo metode v objektu elementa, ki so opisane v razdelku 4.5.3. Za vse ostale atribute pa uporabimo funkcijoget attribute, kjer podamo ime atributa, ki ga ˇzelimo pridobiti.
Ogrodje XCUITest (izpis 5.8) se od naˇsega ogrodja razlikuje v tem, da je moˇzno pridobiti atribute le z metodami, ki so definirane v objektu elementa, kar pomeni, da ostalih atributov ni moˇzno prebrati.
Pri ogrodju Espresso (izpis 5.7) objekti elementov ne ponujajo metod, s katerimi bi lahko pridobivali atribute. Zaradi tega pridobivamo atribute z do- dajanjem nove funkcije, ki kot argument sprejme objekt tipaViewInteraction in iz njega potem pridobi ˇzeleni atribut. ˇCeprav ogrodje Espresso ne pod- pira pridobivanja atributov, lahko njihove vrednosti vseeno preverjamo. To
doseˇzemo s pomoˇcjo objektov tipa ViewAssertion, o katerih bomo veˇc po- vedali v razdelku 5.5.
5.5 Preverjanje trditev
V tem poglavju si bomo pogledali, kako preverimo podane trditve in s tem uspeˇsnost testnega primera.
// Preverjamo , c e e j e v r e d n o s t t e k s t a enaka n i z u ” H e l l o ” u s e r n a m e I n p u t . c h e c k ( matches ( withText (” H e l l o ”) )
Izpis 5.10: Preverjanje trditev z ogrodjem Espresso
// Preverjamo , c e j e v r e d n o s t t e k s t a enaka n i z u ” H e l l o ” XCTAssert ( u s e r n a m e I n p u t . v a l u e a s! S t r i n g == ” H e l l o ”)
Izpis 5.11: Preverjanje trditev z ogrodjem XCUITest”
# Preverjamo , c e j e v r e d n o s t t e k s t a enaka n i z u ” H e l l o ”
a s s e r t u s e r n a m e i n p u t . t e x t == ” H e l l o ”, ” Username t e x t has n o t changed t o H e l l o ”
Izpis 5.12: Preverjanje trditev z uporabo naˇsega ogrodja”
Iz izpisov 5.11 in 5.12 vidimo, da ogrodje XCUITest in naˇse ogrodje upo- rabljata isti pristop za potrjevanje pravilnosti testnega primera. Oba podata logiˇcno vrednost v potrjevalnem stavku. Pri ogrodju XCUITest je to funk- cija XCTAssert, medtem ko pri naˇsem ogrodju uporabljamo kljuˇcno besedo assert, ki je del orodja Pytest.
Ogrodje Espresso za razliko od omenjenih ogrodij preverja pravilnost te- stnih primerov s pomoˇcjo objektov tipa ViewAssertion in ViewMatcher.
Metodicheckpodamo metodo, ki vrne objekt tipaViewAssertion, ki preveri doloˇcen pogoj (na primer, metodamatchessprejme objekt tipaViewMatcher, ki smo ga opisali v razdelku 5.3). Metoda check nato vrne objekt tipa ViewAssertion, ki bo oznaˇcil podani pogoj kot opravljen le v primeru, ko se trenutni element ujema s predikatom, predstavljenim v objektuViewMatcher (izpis 5.10).
