Yleisliittymän testauksen automatisoinnista iOS:ssä on tullut yhtä helppoa kuin yksikkötestien kirjoittamisesta siitä lähtien, kun Apple esitteli XCUI-kehyksen. Tässä postauksessa aion puhua siitä, miten XCUI yhdistettynä kerrokselliseen suunnitteluun voi auttaa automatisoimaan helposti sovelluksia, erityisesti sellaisia, joissa on useita räätälöityjä käyttöliittymäelementtejä. Yksi tällainen sovellus, jossa käytimme tätä laajasti, on VMware Boxer, VMwaren yrityssovellus, joka yhdistää kolme tärkeää toimintoa – sähköpostin, kalenterin ja yhteystiedot. VMware Boxer käyttää useita erilaisia käyttöliittymäelementtejä natiivista UITableView:stä pitkälle räätälöityihin visuaalisiin elementteihin.
Lukijoilla oletetaan olevan peruskäsitys Xcodesta, Objective C:stä, Swiftistä, XCUI-kehyksestä ja Applen kehitysekosysteemistä yleensä. Jos XCUI on sinulle uusi tuttavuus, kannattaa aloittaa ensin tästä.
Kuten mikä tahansa muu UI-automaatioprojekti, tiimimme aloitti kysymällä, mitä automaatiokehystä käyttää. Olimme käyttäneet SeeTestiä. Näimme tämän kuitenkin tilaisuutena tarkistaa automatisointistrategiaamme, kun otetaan huomioon VMware Boxeriin lisätyt uudet, monimutkaiset toiminnot, VMwaren ekosysteemiin kuuluvien tuotteiden määrä ja näiden tuotteiden välinen integraatiotestaus. Seuraavassa on lueteltu harkitsemamme vaihtoehdot-
1. Jatka SeeTestin kanssa
2. Earl Grey
3. XCUI
Vaikka SeeTestillä oli valmiudet suoriutua välittömistä automatisointitarpeistamme, siihen liittyi itsenäinen haaste. Se edellytti, että otimme käyttöön uuden teknologiapinon. Tämä vaatisi lisäkoulutusta iOS-kehittäjille ja omistautuneita asiantuntijoita automaatiojärjestelmän ylläpitoon.
Mitä Appiumista? Emme harkinneet Appiumia samoista syistä, jotka mainittiin edellä SeeTestin kohdalla. Appium on hyvä valinta, jos meillä olisi hybridisovelluksia tai merkittävää jaettua koodia Androidin ja iOS:n välillä.
Earl Grey 1 oli mahdollinen valinta, koska se mahdollisti pysymisen Xcodessa ja Applen kehitystyökaluissa ja se perustui XCTestiin. Earl Grey 1 -automaatio toimii kuitenkin samassa prosessissa kuin testattava sovellus. Toisaalta Applen XCUI-kehykseen perustuva automaatio toimii erillisessä prosessissa kuin testattava sovellus. Tämä on parempi vaihtoehto, koska testattavan sovelluksen ei pitäisi olla muuta kuin musta laatikko sille taholle (automaatioprosessille tai loppukäyttäjälle), joka testaa sen käyttöliittymää.
Automaatioprosessi (joka testaa) pitää eristää varsinaisesta testattavasta sovelluksesta. Testattavan sovelluksen ei pitäisi olla muuta kuin musta laatikko automatisoivalle prosessille.
Mikä tahansa Applen ekosysteemin uusi työkalu, joka ei ole linjassa Applen lähestymistavan kanssa (esim. Earl Grey 1), voi epäonnistua ilman varoitusta. Tällainen lähestymistapa saattaa vaatia paljon vaivaa ylläpitää, jotta se toimisi edelleen Applen uudempien tai tulevien tarjousten kanssa.
Early Grey 2:ssa lisättiin kyky olla vuorovaikutuksessa XCUI:n kanssa. Se oli yritys sovittaa yhteen XCUI:n kanssa, mutta siinä oli näitä tunnettuja ongelmia.
Viimein XCUI oli parempi valinta. Tämän ansiosta kehittäjällä on enemmän määräysvaltaa automatisointiin ja hän hyötyy välittömästi kaikista Applen ekosysteemissä tapahtuvista innovaatioista.
Testattava sovellus ja XCUI-automaatiomoduuli
Ennen kuin siirrymme yksityiskohtiin, on tärkeää toistaa, että XCUI:ta käyttävä automaatiomoduuli toimii testattavasta sovelluksesta riippumattomana prosessina. Aluksi lisäsimme uuden moduulin, johon viittaamme jatkossa nimellä Automation Module(AM). AM on työtila, joka sisältää kokoelman luokkia ja tietorakenteita, joita käytetään VMware Boxer -automaatiossa XCUI:n avulla.
Käytettävyystunnukset
On tärkeää, että sovellusta kehitettäessä pidetään mielessä sen testattavuus. Yksi kehittäjän tehtävistä on varmistaa, että jokaiselle loppukäyttäjälle altistuvalle käyttöliittymäelementille on asetettu saavutettavuustunniste kehityksen aikana. Saavutettavuustunniste on linkki testattavan sovelluksen ja XCUI-automaatioprosessin välillä.
Saavutettavuustunniste on linkki testattavan sovelluksen ja XCUI-automaatioprosessin välillä.
Suunnittelumalli
Kuten aiemmin mainittiin, VMware Boxer on valtava sovellus. Käytettävän suunnittelumallin valintaan päädyttiin pitäen mielessä, että testien tulisi olla helposti toteutettavia, helposti ylläpidettäviä, uudelleenkäytettäviä, vankkoja ja skaalautuvia. Alla olevassa sisällössä selitetään VMware Boxerin XCUI-automaatiomoduulin arkkitehtuurin kerrokset:
Seuraavassa kuvassa on esitetty perusrakennuspalikat:
Testausluokat
Tässä kerroksessa on luokat, joissa on testimenetelmät. Tämän kerroksen tarkoituksena on, että testit koostuvat minimaalisesta koodista, joka kertoo vain sen, mitä testataan. Lisäksi testit toteuttavan kehittäjän on ajateltava vain korkean tason sovellusvirtaa, jota tarvitaan testattavien asioiden testaamiseen. Loput monimutkaisuudesta (esim. miten navigoidaan käyttöliittymään, jossa haluttu testaus voidaan suorittaa) olisi abstrahoitava uudelleenkäytettäviin kerroksiin. Alla olevassa kuvassa on esimerkki testimenetelmästä, joka selittää edellä esitetyn tarkoituksen – koodissa testataan, voiko Asetukset-käyttöliittymän avulla ottaa käyttöön/poistaa käytöstä ominaisuuden tai onko siinä tarvittavat kytkinohjaimet.
Testejä kirjoittava kehittäjä voisi siis kirjoittaa koodia, joka on yhtä yksinkertaista kuin pseudokoodi. Samalla on selvää, että jotain logiikkaa on kutsuttava seuraavasta kerroksesta (Flows : selitetään seuraavassa kappaleessa).
Flows-luokat
Flows edustaa kokoelmaa luokkia, jotka tarjoavat eri Tests-luokkien tarvitsemia toiminnallisuuksia. Toiminnallisuuksia voivat olla esimerkiksi sovelluksen asettaminen ennen todellisen testitapauksen suorittamista tai navigointi tiettyyn testattavan sovelluksen osaan. Useimmat näistä toiminnallisuuksista ovat uudelleenkäytettäviä ja niitä tarvitaan useissa testeissä. esim. yllä oleva esimerkkitestitapaus edellyttää, että 1. sovellus käynnistetään. ja 2. sovellus käynnistetään. Siirrytään Feature Controller -ohjaimen asetusnäyttöön.
Siten Flow-luokkia kutsuttaisiin testeistä ja ne toteuttaisivat virrat, kuten ”Siirry asetuksiin” tai ”Siirry Feature Controller -ohjaimen asetuksiin”.
Näyttöluokat
Näyttöluokat ovat luokkia, joilla on yksi yhteen -mappaus vastaaviin View Controllereihin. View Controller voidaan korkealla tasolla nähdä luokkana, jolla on (taustanäkymässä) UIControls ja metodeja, jotka reagoivat käyttäjän vuorovaikutukseen näiden UIControlsien kanssa. Screen-luokka on yksinkertaisesti View Controller -luokan proxy-kartoitus. Jäljempänä olevassa kuvassa on esitetty tämä kartoitus. Käyttöliittymässä on solu Initial View, ja kun käyttäjä napauttaa tätä solua, käyttäjä voi valita, mikä merkitään sovelluksen alkuperäiseksi näkymäksi. Alla olevassa kuvassa näytetään, miten Screen-luokka toteutetaan edellä mainitun vaatimuksen kartoittamiseksi.
Tämän Screen-luokan pseudokoodi näyttäisi seuraavanlaiselta: –
// 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"
}
mikä on boxerApp yllä olevassa koodissa? Yllä olevassa koodissa boxerApp edustaa yksikköä, joka on BoxerApp-luokan instanssi, joka kapseloi testattavan sovelluksen ja sen näytöt. Tämä selitetään seuraavassa kappaleessa.
Yllä oleva koodi mallintaa VMware Boxerin SettingFormViewControlleria. Luokan nimeämisessä käytetään konventiota, jonka mukaan nimi johdetaan näkymäohjaimen nimestä korvaamalla loppuliite ViewController sanalla Screen. Huomaa myös mukavuusluokka, jolla on saavutettavuustunnisteet.
Käytettävyystunniste on yhteinen linkki testattavan sovelluksen ja XCUI-automaatioprosessin välillä.
Putting it Together: VMware Boxer XCUI-automaatiomoduuli
UITest-moduuli testaa käynnissä olevan sovelluksen. On tärkeää, että sovellusmalli suunnitellaan siten, että yksi testattavan sovelluksen instanssi on yksi yksikkö. Tämä tarkoittaa, että testattava sovellus tulisi nähdä kokoelmana näyttöluokkia, jotka osallistuvat liiketoimintavirtoihin (kokoelma flow-luokkia)joita kutsutaan testeistä (kokoelma luokkia)testin vaatimuksen perusteella. Jokaisessa sovellusyksikössä pitäisi olla täsmälleen yksi instanssi jokaisesta Screen-luokasta, joka vastaa yhtä näkymäohjainta.
Miten tämä saavutetaan?
XCUITestisarja voi saavuttaa tämän kapseloimalla testattavan sovelluksen instanssin(XCUIApplication) yhteen yksikköön, esim. BoxerApp-luokka, jolla on jäsensovellus ja jossa on kaikki kyseisen sovelluksen näytöt. Alla olevassa kuvassa selitetään tämä kapselointi
Siten ennen kuin XCUITest-sarja käynnistyy, se loisi ensimmäisenä BoxerApp-moduulin instanssin testattavan sovelluksen bundle-tunnisteen avulla. Alla oleva kuva selittää tämän
Testit::testMethod välittää tämän jälkeen tämän BoxerApp-instanssin (yksikkö, joka kapseloi XCUIAsovelluksen ja Näytöt -moduulin) ensimmäisenä parametrinaan kohteelle Virtaukset::virtausmenetelmä.
Vuorostaan Flows::flowMethod kutsuu Screen::screenMethod-metodia ja välittää sille tarvittaessa BoxerAppin.
Viimein vuorovaikutus sovelluksen käyttöliittymän kanssa tapahtuu Screen::screenMethodin kautta.
Oheisessa kuvassa on esitetty edellä kuvattu rakenne.
Johtopäätös
XCUI-testien kirjoittaminen voi olla hankalaa ja hallitsematonta, jos sitä ei tehdä suunnitelmallisesti. Toivottavasti tämä postaus antaa hyödyllisiä vihjeitä siitä, miten ajatella automaatioprojektin jäsentämistä modulaarisesti, siististi ja kerroksittain.
Mitä seuraavaksi?
Aion käsitellä näitä aiheita suunnittelemassani juttusarjassa:
XCUI : Osa 2 -Vuorovaikutus natiivisovellusten kanssa puhtaasti
XCUI : Osa 3 -Kuinka XCUI-runtime voi olla vuorovaikutuksessa testattavan sovelluksen kanssa puhtaasti.
XCUI : Osa 4 -Järjestelmähälytysten käsittely.
XCUI : Osa 5 -Testin etenemisen seuraaminen ja raporttien käyttäminen sekä kuvakaappausten ottaminen.
XCUI : Osa 5 -Testin etenemisen seuraaminen ja raporttien käyttäminen sekä kuvakaappausten ottaminen.