I dispositivi iOS rivendicano ancora una parte significativa del mercato mobile, prendendo fino al 22% delle vendite a livello globale. Poiché molti clienti devoti tornano per i nuovi prodotti Apple, c’è anche una grande richiesta di applicazioni iOS. In questo articolo, ci occuperemo di garantire la qualità delle applicazioni iOS cercando di utilizzare le migliori pratiche con gli strumenti Appium, Cucumber e Serenity.

Struttura

Il Page Object Model è uno dei migliori approcci ai test che gli ingegneri QA possono applicare a un progetto di test automation. È un modo di strutturare il codice in un progetto di automazione che migliora la qualità e la leggibilità del codice, la manutenzione dei test e, soprattutto, è un ottimo modo per evitare il caos. L’idea di base è quella di mantenere tutti i riferimenti agli elementi mobili e ai metodi che eseguono operazioni su di essi in un unico file di classe per ogni pagina o schermo dell’applicazione (o pagina web per applicazioni web non native).

Quali sono i vantaggi di questo approccio, vi chiederete? In primo luogo, rende l’automazione molto semplice. Fondamentalmente, significa trovare elementi nella nostra app iOS tramite l’ispettore e poi eseguire operazioni su di essi. Un altro vantaggio principale è la struttura coerente del progetto che permette a chiunque di navigarlo rapidamente.

Prendiamo un esempio di un’app che contiene ricette. All’avvio mostra il ricettario predefinito con le ricette di base, che sarà la nostra prima pagina. Da lì, un utente può navigare verso qualsiasi ricetta disponibile, segnando così una seconda pagina. Oltre a questo, l’applicazione permette anche di sfogliare altri libri di cucina o di acquistare quelli premium, rendendola la terza pagina e di conseguenza – un file oggetto di pagina.

Similmente, dovremmo creare i file di definizione dei passi corrispondenti. Questa non è una pratica obbligatoria, ma tenere tutte le definizioni dei passi in un solo posto provoca un caos inutile.

Mentre si creano le pagine e i file di classe di definizione dei passi si consiglia di scegliere nomi che sono legati alla pagina (schermata dell’app) su cui si sta per lavorare. Nominare questi file dopo una caratteristica o uno scenario può sembrare giusto a prima vista, ma man mano che il progetto si espande, si noterà sempre più disordine nella sua struttura. Adottare la convenzione di denominazione delle pagine assicura che chiunque sia coinvolto nel progetto possa familiarizzare subito con esso e iniziare a collaborare in poco tempo. Tale pratica contribuisce anche alla riusabilità del codice – sia delle definizioni dei passi che dei metodi/funzioni.
Al contrario dei file di definizione dei passi e dei passi menzionati, i file delle caratteristiche di Cucumber dovrebbero avere il nome di una caratteristica che verificano. Intelligente, vero? E ancora, strutturarli in directory nominate in relazione ad un particolare campo dell’applicazione sotto test renderà la struttura più significativa.
Il concetto base di Serenity è di essere una “documentazione vivente”. Pertanto, dare agli scenari di test e ai file delle caratteristiche nomi appropriati aiuta il team e le parti interessate a capire meglio i rapporti e l’intero progetto.

Un altro ingrediente che espande i benefici del Page Object Model nel progetto di automazione dei test è PageFactory. È uno strumento che aiuta a ridurre il lavoro di codifica e a mettere facilmente i localizzatori MobileElements nel codice, usando la notazione @FindBy. Da lì, trovare gli elementi per farli interagire con Appium nei test è molto più semplice.

Assertion

L’esecuzione di test tramite Appium può richiedere molte risorse. Per rendere le cose più facili per la vostra macchina MacOS che esegue i test sul vostro dispositivo iOS, assicuratevi di non asserire costantemente la visibilità di tutti gli oggetti su una pagina. Questa pratica aumenta significativamente il tempo di esecuzione del test, che di solito non è la cosa più desiderabile.

Inoltre, quando devi controllare se un elemento è visibile, abilitato, cliccabile, o qualsiasi cosa nel mezzo – cerca di evitare di localizzare gli elementi mobili usando Xpath. Il suggerimento dell’ispettore Appium ha un punto valido! Dovresti fare il possibile per convincere il team di sviluppo a fare uno sforzo in più e assegnare ID e nomi unici agli elementi dell’app. Questo non solo renderà i test di automazione più facili e veloci, ma renderà il tuo lavoro di tester più efficace, aumentando così la qualità complessiva del prodotto. Ed è per questo che siamo qui. Per non parlare del fatto che la manutenzione dei test (ad esempio il passaggio a diversi localizzatori quando necessario) diventerà molto più piacevole.

Comprendere i passi

Un altro aspetto dell’impostazione di questo tipo di progetto si riduce a sfruttare Cucumber e a usare il linguaggio Gherkin.

Gherkin implementa un approccio diretto con la notazione Given, When, Then con l’aiuto degli aggiuntivi And e But che sembra abbastanza facile da usare. Potreste scrivere praticamente qualsiasi cosa vogliate nei passi di test dei vostri file di funzionalità. In definitiva, i metodi chiamati eseguiranno delle azioni.

Ma la ragione per usare l’approccio Behavior Driven Development e Cucumber stesso è permettere alle persone non tecniche coinvolte nel progetto di capire cosa sta succedendo nel campo dei test. Non solo, scrivere scenari di test in modo Given/When/Then può anche agire a vostro vantaggio. Tali descrizioni di test di alto livello fornite dal cliente o dall’analista di business vi faranno codificare in pochissimo tempo, a condizione che siano scritte correttamente. Ecco alcuni suggerimenti utili:
Gli scenari di test scritti in Gherkin dovrebbero concentrarsi sul comportamento dell’applicazione (quindi Behavior Driven Development).
Ecco un esempio di come NON scrivere scenari di test in Gherkin, esplorando ulteriormente il tema dell’applicazione cookbook:

L’esempio precedente illustra due cattive pratiche che dovremmo evitare: Si concentra sull’implementazione invece che sul comportamento e usa valori hard-coded piuttosto che scrivere passi di test in modo tale da permettere la riusabilità cambiando i valori all’interno di un passo.

Pertanto, uno scenario corretto riguardante l’acquisto di un libro di ricette nella nostra app di esempio dovrebbe assomigliare a:

Un altro esempio:

Adottare questo approccio significa meno lavoro nel creare e codificare i passi di test ogni volta che l’implementazione di una particolare caratteristica cambia.

Oltre alla notazione principale di Given/When/Then, Cucumber supporta l’uso di passi di congiunzione. L’uso delle notazioni And e But rende i passi di test più generali e riutilizzabili, il che porta a scrivere meno codice e a mantenere l’ordine nel progetto. Ecco un esempio di base:

Così facendo, se si codifica il passo ‘Given’ di cui sopra per individuare il nostro elemento ricetta cercando il suo nome, è possibile riutilizzarlo molte volte semplicemente cambiando il valore della stringa nel passo (a condizione di codificare correttamente la definizione del passo in seguito). Inoltre, il passo ‘And’ può essere parte di qualsiasi scenario di test che implica tale azione.

Mettere tutto insieme

Dopo aver impostato un progetto utilizzando le pratiche descritte sopra, le parti più visibili dell’utilizzo di Serenity sono i rapporti di test generati. Dopo aver adottato il tag @RunWith(CucumberWithSerenity.class) nel vostro file di classe TestRunner, l’esecuzione della suite di test porterà Serenity a generare un rapporto aggregato sui risultati dei test, che può essere utile per valutare la qualità dell’app sotto test e presentare lo stato del prodotto agli stakeholder o al team di sviluppo.

Appium, Cucumber, Serenity – Summary

Come potete vedere, il concetto di best practice nei test di automazione può essere riassunto in tre parole: riusabilità, leggibilità e performance. Riusabilità significa meno codificazioni, di conseguenza diminuisce il tempo necessario per finire il lavoro. La leggibilità migliora la comprensione, che è cruciale per garantire che il prodotto faccia ciò che deve fare. Infine, la performance fa risparmiare tempo di esecuzione e migliora la stabilità. Tutti e tre contribuiscono non solo alla qualità del progetto di automazione dei test, ma hanno un ruolo significativo nel migliorare la qualità complessiva dell’app consegnata.