Automatizarea testării interfețelor utilizator pe iOS a devenit la fel de ușoară ca și scrierea testelor unitare de când Apple a introdus cadrul XCUI. În această postare, voi vorbi despre modul în care XCUI, împreună cu designul stratificat, poate ajuta la automatizarea cu ușurință a aplicațiilor, în special a celor cu mai multe elemente de interfață personalizată. O astfel de aplicație în care am folosit acest lucru pe scară largă este VMware Boxer, o aplicație de întreprindere de la VMware care reunește trei funcții importante – Email, Calendar și Contacte. VMware Boxer utilizează mai multe tipuri de elemente de interfață utilizator, de la UITableView nativ la elemente vizuale foarte personalizate.
Se presupune că cititorii au cunoștințe de bază despre Xcode, Objective C, Swift, cadrul XCUI și ecosistemul de dezvoltare Apple în general. Dacă sunteți nou în XCUI, ar trebui să începeți mai întâi de aici.
Ca orice alt proiect de automatizare a interfețelor utilizator, echipa noastră a început cu o întrebare despre ce cadru de automatizare să folosească. Noi folosisem SeeTest. Cu toate acestea, am considerat că aceasta este o oportunitate de a ne revizui strategia de automatizare, având în vedere funcționalitatea nouă și complexă adăugată în VMware Boxer, numărul de produse din ecosistemul VMware și testele de integrare între aceste produse. Iată care au fost alegerile pe care le-am luat în considerare-
1. 1. Continuăm cu SeeTest
2. Earl Grey
3. XCUI
În timp ce SeeTest avea capacitatea de a face față nevoilor noastre imediate de automatizare, a existat o provocare independentă cu care trebuia să ne confruntăm. Aceasta ne cerea să adoptăm o nouă stivă tehnologică. Acest lucru ar fi necesitat instruire suplimentară pentru dezvoltatorii iOS și experți dedicați pentru a menține sistemul de automatizare.
Ce ziceți de Appium? Nu am luat în considerare Appium din aceleași motive menționate mai sus pentru SeeTest. Appium este o alegere bună dacă aveam aplicații hibride sau cod partajat semnificativ între Android și iOS.
Earl Grey 1 a fost o alegere posibilă, având în vedere că ne permitea să rămânem în Xcode și în instrumentele de dezvoltare Apple și se baza pe XCTest. Cu toate acestea, automatizarea Earl Grey 1 se execută în același proces cu aplicația testată. Pe de altă parte, automatizarea bazată pe cadrul XCUI de la Apple se execută într-un proces separat față de aplicația testată. Acest lucru este de preferat, deoarece aplicația testată nu ar trebui să fie nimic mai mult decât o cutie neagră pentru entitatea (un proces de automatizare sau un utilizator final) care îi testează interfața de utilizare.
Treceți procesul de automatizare (cel care testează) izolat de aplicația efectivă testată. Aplicația testată nu ar trebui să fie nimic mai mult decât o cutie neagră pentru procesul de automatizare.
Orice instrument nou din ecosistemul Apple care nu este aliniat cu abordarea Apple (de exemplu, Earl Grey 1) poate eșua fără avertisment. O astfel de abordare poate necesita mult efort de întreținere pentru a continua să funcționeze cu ofertele mai noi sau viitoare ale Apple.
Early Grey 2 a adăugat capacitatea de a interacționa cu XCUI. A fost o încercare de a se alinia cu XCUI, dar a avut aceste probleme cunoscute.
În cele din urmă, XCUI a fost alegerea preferată. Cu aceasta, un dezvoltator va avea mai mult control asupra automatizării și va fi beneficiarul imediat al oricărei inovații din ecosistemul Apple.
Aplicația testată și modulul de automatizare XCUI
Înainte de a intra în detalii, este important să reiterăm faptul că modulul de automatizare care utilizează XCUI rulează ca un proces independent de aplicația care este testată. Pentru început, am adăugat un nou modul la care ne vom referi de acum încolo ca modul de automatizare(AM). AM este un spațiu de lucru care conține o colecție de clase și structuri de date utilizate pentru automatizarea VMware Boxer folosind XCUI.
Identificatori de accesibilitate
Este important ca aplicația să fie dezvoltată având în vedere testabilitatea acesteia. Una dintre responsabilitățile dezvoltatorului este de a se asigura că fiecare element de interfață utilizator care este expus utilizatorului final are identificatorul de accesibilitate setat în timpul dezvoltării. Identificatorul de accesibilitate este legătura dintre aplicația în curs de testare și procesul de automatizare XCUI.
Identificatorul de accesibilitate este legătura dintre aplicația în curs de testare și procesul de automatizare XCUI.
Design Pattern
După cum am menționat anterior, VMware Boxer este o aplicație uriașă. La alegerea modelului de proiectare care urmează să fie utilizat s-a ajuns ținând cont de faptul că testele trebuie să fie ușor de implementat, ușor de întreținut, reutilizabile, robuste și scalabile. Conținutul de mai jos explică straturile arhitecturii modulului de automatizare XCUI pentru VMware Boxer:
Figura următoare prezintă blocurile de bază:
Classe de testare
Acest strat este cel care are clasele care au metodele de testare. Intenția acestui strat este de a avea teste care să cuprindă un cod minim care să spună doar ceea ce se testează. De asemenea, dezvoltatorul care implementează testele trebuie să se gândească doar la fluxul aplicației de nivel înalt necesar pentru a testa ceea ce se testează. Restul complexității (de exemplu, modul de navigare către interfața de utilizare în care se poate efectua testarea dorită) ar trebui să fie abstractizat în straturi reutilizabile. Consultați imaginea de mai jos care prezintă un exemplu de metodă de testare care explică intenția de mai sus – codul testează dacă o interfață de utilizator Settings UI poate ajuta la activarea/dezactivarea unei funcții sau dacă are controale de comutare necesare.
Deci, dezvoltatorul care scrie testele ar putea scrie un cod care este la fel de simplu ca un pseudocod. Între timp, este clar că o anumită logică ar trebui să fie invocată din stratul următor (Flows : explicat în secțiunea următoare).
Classe de Flows
Flows reprezintă o colecție de clase care oferă funcționalități necesare pentru diferite clase de Teste. Funcționalitățile pot include configurarea aplicației înainte de a executa cazul de testare real sau navigarea către o anumită parte a aplicației testate. Cele mai multe dintre aceste funcționalități sunt reutilizabile și necesare în mai multe teste. de exemplu, exemplul de caz de test de mai sus necesită ca 1. aplicația să fie lansată și 2. aplicația să fie lansată. Se navighează către un ecran de setări al unui controler de caracteristici.
Deci, clasele Flow ar fi invocate din teste și ar implementa fluxuri precum „Navigate to Settings” sau „Navigate to Feature Controller Settings”.
Classele de ecrane
Classele de ecrane sunt clase care au o corespondență unu-la-unu cu controlorii de vizualizare respectivi. Un controler de vizualizare poate fi, la nivel înalt, văzut ca o clasă care are (în vederea de fundal) UIControls și metode care răspund la interacțiunea utilizatorului cu acele UIControls. O clasă Screen este pur și simplu o corespondență proxy a View Controller. Figura de mai jos prezintă această cartografiere. Există o celulă Initial View (Vizualizare inițială) în UI, iar atunci când utilizatorul atinge această celulă, acesta poate selecta ceea ce ar trebui să fie marcat ca vizualizare inițială pentru aplicație. Figura de mai jos arată modul în care este implementată o clasă Screen pentru a cartografia cerința de mai sus.
Pudocod pentru această clasă Screen ar arăta astfel –
// 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"
}
ce este boxerApp în codul de mai sus? În codul de mai sus, boxerApp reprezintă o unitate care este o instanță a clasei BoxerApp care încapsulează aplicația testată și ecranele sale. Acest lucru este explicat în secțiunea următoare.
Codul de mai sus modelează SettingFormViewController din VMware Boxer. Convenția utilizată în denumirea clasei este că numele este derivat din numele controlerului de vizualizare prin înlocuirea sufixului ViewController cu Screen. Observați, de asemenea, clasa de conveniență care are identificatori de accesibilitate.
Identificatorul de accesibilitate este legătura comună între aplicația testată și procesul de automatizare XCUI.
Punând totul laolaltă: Modulul de automatizare VMware Boxer XCUI
Modulul UITest testează aplicația care rulează. Este important ca modelul aplicației să fie proiectat astfel încât o instanță a aplicației testate să fie o singură unitate. Aceasta înseamnă că aplicația testată trebuie văzută ca o colecție de clase de ecrane care participă la fluxuri de afaceri (colecție de clase de fluxuri)care sunt invocate din teste (colecție de clase)în funcție de cerința testului. Fiecare unitate de aplicație ar trebui să aibă exact o instanță a fiecărei clase de ecran care corespunde unui controler de vizualizare.
Cum se poate realiza acest lucru?
O suită de teste XCUITest poate realiza acest lucru prin încapsularea instanței aplicației supuse testului (XCUIApplication) într-o singură unitate, de exemplu clasa BoxerApp care are o aplicație membră și are toate ecranele pentru acea aplicație. Figura de mai jos explică această încapsulare
Prin urmare, înainte ca suita XCUITest să pornească, primul lucru pe care l-ar face este să creeze o instanță a modulului BoxerApp folosind identificatorul de pachet al aplicației testate. Figura de mai jos explică acest lucru
Această instanță a BoxerApp (unitatea care încapsulează aplicația XCUIApplication și ecranele) este apoi transmisă de Tests::testMethod către Flows::flowMethod ca prim parametru.
Metoda Flows::flowMethod apelează la rândul său la Screen::screenMethod și trece BoxerApp dacă este necesar.
În cele din urmă, interacțiunea cu interfața utilizator a aplicației are loc prin Screen::screenMethod.
Figura de mai jos prezintă proiectarea de mai sus.
Concluzie
Scrierea testelor XCUI poate fi greoaie și imposibil de gestionat dacă nu se face cu un plan. Sper că această postare vă oferă indicii utile despre cum să vă gândiți la structurarea proiectului de automatizare într-un mod modular, curat și stratificat.
Ce urmează?
Voi aborda aceste subiecte în seria de povestiri pe care o planific:
XCUI : Partea 2 -Interacțiunea cu aplicațiile native într-un mod curat
XCUI : Partea 3 -Cum poate interacționa XCUI runtime cu aplicația testată într-un mod curat.
XCUI : Partea 4 -Manipularea alertelor de sistem.
XCUI : Partea 5 -Observarea progresului testului și accesarea rapoartelor și capturarea capturilor de ecran.
.