L’automazione dei test UI su iOS è diventata facile come scrivere test unitari da quando Apple ha introdotto il framework XCUI. In questo post, parlerò di come XCUI, insieme al design a strati, può aiutare ad automatizzare facilmente le applicazioni, specialmente quelle con più elementi UI personalizzati. Una di queste applicazioni in cui abbiamo usato ampiamente questo sistema è VMware Boxer, un’applicazione aziendale di VMware che aggrega tre importanti funzioni: e-mail, calendario e contatti. VMware Boxer usa diversi tipi di elementi UI, dalla UITableView nativa a elementi visivi altamente personalizzati.
Si presume che i lettori abbiano una conoscenza di base di Xcode, Objective C, Swift, il framework XCUI e l’ecosistema di sviluppo Apple in generale. Se siete nuovi di XCUI, dovreste iniziare da qui.
Come ogni altro progetto di automazione UI, il nostro team ha iniziato con una domanda su quale framework di automazione usare. Avevamo usato SeeTest. Tuttavia, abbiamo visto questa come un’opportunità per rivedere la nostra strategia di automazione data la nuova e complessa funzionalità aggiunta in VMware Boxer, il numero di prodotti nell’ecosistema VMware e i test di integrazione tra questi prodotti. Di seguito le scelte che abbiamo considerato-
1. Continuare con SeeTest
2. Earl Grey
3. XCUI
Mentre SeeTest aveva la capacità di gestire le nostre esigenze immediate di automazione, c’era una sfida indipendente da affrontare. Ci richiedeva di adottare un nuovo stack tecnologico. Ciò avrebbe richiesto una formazione aggiuntiva per gli sviluppatori iOS ed esperti dedicati alla manutenzione del sistema di automazione.
E Appium? Non abbiamo considerato Appium per le stesse ragioni menzionate sopra per SeeTest. Appium è una buona scelta se avessimo app ibride o codice condiviso significativo tra Android e iOS.
Earl Grey 1 era una possibile scelta, dato che ci permetteva di rimanere in Xcode e negli strumenti di sviluppo Apple ed era basato su XCTest. L’automazione Earl Grey 1, tuttavia, viene eseguita nello stesso processo dell’applicazione sotto test. D’altra parte, l’automazione basata sul framework XCUI di Apple viene eseguita in un processo separato dall’applicazione sotto test. Questo è preferito poiché l’applicazione sotto test non dovrebbe essere altro che una scatola nera per l’entità (un processo di automazione o un utente finale) che sta testando la sua UI.
Avere il processo di automazione (quello che sta testando) isolato dall’effettiva applicazione sotto test. L’applicazione sotto test non dovrebbe essere altro che una scatola nera per il processo di automazione.
Ogni nuovo strumento nell’ecosistema Apple che non è allineato con l’approccio di Apple (ad esempio Earl Grey 1) può fallire senza preavviso. Un tale approccio può richiedere un grande sforzo di manutenzione per continuare a lavorare con offerte più recenti o future di Apple.
Early Grey 2 ha aggiunto la capacità di interagire con XCUI. Era un tentativo di allinearsi con XCUI ma aveva questi problemi noti.
Alla fine, XCUI fu la scelta preferita. Con questo, uno sviluppatore avrà più controllo sull’automazione e sarà il beneficiario immediato di qualsiasi innovazione nell’ecosistema Apple.
App in prova e modulo di automazione XCUI
Prima di entrare nei dettagli, è importante ribadire che il modulo di automazione che usa XCUI viene eseguito come un processo indipendente dall’applicazione in prova. Per iniziare, abbiamo aggiunto un nuovo modulo che d’ora in poi chiameremo Automation Module(AM). AM è uno spazio di lavoro che contiene una collezione di classi e strutture dati utilizzate per l’automazione di VMware Boxer utilizzando XCUI.
Identificatori di accessibilità
È importante che l’applicazione sia sviluppata tenendo presente la sua testabilità. Una delle responsabilità dello sviluppatore è assicurare che ogni elemento dell’interfaccia utente che è esposto all’utente finale abbia l’identificatore di accessibilità impostato durante lo sviluppo. L’identificatore di accessibilità è il collegamento tra l’applicazione sotto test e il processo di automazione XCUI.
L’identificatore di accessibilità è il collegamento tra l’applicazione sotto test e il processo di automazione XCUI.
Design Pattern
Come detto prima, VMware Boxer è un’applicazione enorme. La scelta del design pattern da utilizzare è stata fatta tenendo presente che i test devono essere facili da implementare, facili da mantenere, riutilizzabili, robusti e scalabili. Il contenuto sottostante spiega i livelli dell’architettura del modulo XCUI Automation per VMware Boxer:
La figura seguente mostra gli elementi di base:
Classi di test
Questo è il livello che ha le classi con i metodi di test. L’intenzione di questo livello è di avere dei test composti da codice minimo che dice solo ciò che viene testato. Inoltre, lo sviluppatore che implementa i test ha bisogno di pensare solo al flusso dell’applicazione di alto livello richiesto per testare ciò che viene testato. Il resto della complessità (ad esempio come navigare verso l’UI dove il test desiderato può essere eseguito) dovrebbe essere astratto in strati riutilizzabili. Fate riferimento all’immagine qui sotto che mostra un metodo di test di esempio che spiega l’intento di cui sopra – il codice testa se una UI Settings può aiutare ad attivare/disattivare una funzione o se ha i controlli di commutazione richiesti.
Quindi, lo sviluppatore che sta scrivendo i test potrebbe scrivere codice semplice come pseudo codice. Nel frattempo, è chiaro che una certa logica dovrebbe essere invocata dal livello successivo (Flussi: spiegato nella prossima sezione).
Classi di Flussi
I Flussi rappresentano un insieme di classi che forniscono le funzionalità richieste per varie classi di Test. Le funzionalità potrebbero includere l’impostazione dell’applicazione prima dell’esecuzione del vero caso di test o la navigazione verso una certa parte dell’applicazione sotto test. La maggior parte di queste funzionalità sono riutilizzabili e richieste in più test. Ad esempio, il caso di test di esempio di cui sopra richiede che 1. l’app sia lanciata e 2.
Così, le classi Flow verrebbero invocate dai test e implementerebbero flussi come “Navigate to Settings” o “Navigate to Feature Controller Settings”.
Classe Schermi
Gli schermi sono classi che hanno una mappatura uno a uno con i rispettivi View Controller. Un View Controller può essere, ad alto livello, visto come una classe che ha (nella vista di supporto) UIControls e metodi che rispondono all’interazione dell’utente con questi UIControls. Una classe Screen è semplicemente una mappatura proxy del View Controller. La figura seguente mostra questa mappatura. C’è una cella Initial View nell’UI e quando l’utente tocca questa cella, l’utente può selezionare ciò che dovrebbe essere segnato come vista iniziale per l’applicazione. La figura qui sotto mostra come una classe Schermo è implementata per mappare il requisito di cui sopra.
Lo pseudo codice per questa classe schermo sarebbe come –
// 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"
}
che cos’è boxerApp nel codice sopra? Nel codice precedente boxerApp rappresenta un’unità che è un’istanza della classe BoxerApp che incapsula l’applicazione sotto test e le sue schermate. Questo è spiegato nella prossima sezione.
Il codice qui sopra modella il SettingFormViewController di VMware Boxer. La convenzione usata nel nominare la classe è che il nome deriva dal nome del view controller sostituendo il suffisso ViewController con Screen. Notate anche la classe di convenienza che ha identificatori di accessibilità.
L’identificatore di accessibilità è il collegamento comune tra l’applicazione in prova e il processo di automazione XCUI.
Mettere tutto insieme: VMware Boxer XCUI Automation Module
Il modulo UITest testa l’applicazione in esecuzione. È importante che il modello dell’applicazione sia progettato in modo tale che un’istanza dell’applicazione sotto test sia una singola unità. Questo significa che l’applicazione sotto test dovrebbe essere vista come una collezione di classi di schermi che partecipano a flussi di business (collezione di classi di flusso) che sono invocati dai test (collezione di classi) in base al requisito del test. Ogni unità di applicazione dovrebbe avere esattamente un’istanza di ogni classe Screen che corrisponde a un view controller.
Come raggiungere questo obiettivo?
Una suite XCUITest può raggiungere questo obiettivo incapsulando l’istanza dell’applicazione sotto test (XCUIApplication) in una unità, ad esempio la classe BoxerApp che ha un’applicazione membro e ha tutte le schermate per quell’applicazione. La figura qui sotto spiega questo incapsulamento
Quindi, prima che la suite XCUITest inizi, la prima cosa che farebbe è creare un’istanza del modulo BoxerApp usando l’identificatore del bundle dell’applicazione in prova. La figura qui sotto spiega questo
Questa istanza di BoxerApp (l’unità che incapsula XCUIApplication e Screens) viene poi passata da Tests::testMethod a Flows::flowMethod come primo parametro.
Il Flows::flowMethod chiama a sua volta Screen::screenMethod e passa BoxerApp se necessario.
Infine l’interazione con l’UI dell’applicazione avviene attraverso Screen::screenMethod.
La figura seguente mostra il design di cui sopra.
Conclusione
Scrivere test XCUI può essere macchinoso e ingestibile se non è fatto con un piano. Spero che questo post fornisca indicazioni utili su come pensare a strutturare il vostro progetto di automazione in modo modulare, pulito e stratificato.
Cosa c’è dopo?
Ho intenzione di coprire questi argomenti nella serie di storie che sto pianificando:
XCUI: Parte 2 -Interagire con le applicazioni native in modo pulito
XCUI: Parte 3 -Come XCUI runtime può interagire con l’applicazione in prova in modo pulito.
XCUI: Parte 4 -Gestire gli avvisi di sistema.
XCUI: Parte 5 -Osservare l’avanzamento dei test, accedere ai rapporti e catturare screenshot.