Test dell'interfaccia utente Android e iOS con Calabash

Il test è una parte essenziale di qualsiasi processo di sviluppo di app mobili. Indipendentemente dal fatto che tu stia automatizzando tali test o meno, nessuno sviluppatore sano di mente considera che il proprio lavoro sia terminato a meno che non abbiano testato la propria app.

Un'app ben testata di solito passa attraverso più fasi di test: test di unità, test di integrazione, test di accettazione e così via. Man mano che la tua app cresce, l'importanza dei test aumenta e l'automazione nei test diventa una necessità.

Mentre altre piattaforme, come il Web, sono notevolmente avanzate in termini di meccanismi di test e framework, il regno mobile non è in ritardo. In questo articolo imparerai come utilizzare Calabash per automatizzare l'interfaccia utente per le tue app Android e iOS utilizzando semplici istruzioni in inglese e rendere i test di accettazione il più indolore possibile.

In cosa consiste il test dell'interfaccia utente?

Se hai testato le tue app manualmente, probabilmente stai sprecando gran parte del tuo tempo eseguendo le stesse attività più e più volte. Apporti alcune modifiche al codice, costruisci l'app, la esegui in un dispositivo o un emulatore e giocherella con l'app per capire se funziona come previsto.

Automatizzando i test dell'interfaccia utente, puoi eseguire automaticamente gli stessi passaggi manuali. Se la tua app è di dimensioni decenti, questo può farti risparmiare molto tempo e anche evitare che la tua app sia piena di bug imbarazzanti, specialmente quelli di regressione.

"Sembra fantastico", dici, ma come lo fai per la tua app Android o iOS?

Framework di test dell'interfaccia utente per Android e iOS

Se leggi la documentazione ufficiale per Android e iOS, ti suggeriscono di scrivere ed eseguire test dell'interfaccia utente nei loro IDE ufficiali. Per Android è Android Studio e per iOS è Xcode.

La documentazione ufficiale arriva al punto di raccomandare framework specifici per il test. La documentazione ufficiale di Android copre alcuni argomenti su Espresso, il framework di test dell'interfaccia utente di Android. Allo stesso modo, Apple suggerisce di utilizzare il framework XCTest.

E se hai intenzione di lavorare seriamente sui test dell'interfaccia utente, potresti seguire questi suggerimenti, il che ha senso poiché Espresso è gestito da Google e fa parte di Android Support Repository. È molto probabile che Espresso supporterà tutte le novità che Google introdurrà per Android in futuro. Potresti dire lo stesso del framework XCTest per iOS.

Tuttavia, vale la pena tenere a mente che, nonostante i numerosi vantaggi dei test automatizzati, molti sviluppatori semplicemente non li scrivono affatto.

Ogni sviluppatore che è a conoscenza delle automazioni dei test, nel profondo, sa che è un'ottima idea. Ma, quando si tratta di sedersi e scrivere questi test, molti sviluppatori iniziano a chiedersi se ne vale la pena, perché "toccare il pulsante" manualmente risulta essere un'operazione molto più veloce rispetto alla scrittura di un codice che "tocca questo pulsante" automaticamente. A volte, anche i clienti e i gestori, in trepidante attesa di provare l'app, non aiutano.

Molti sviluppatori, a quel punto, decidono che è meglio continuare a lavorare sulle nuove funzionalità dell'applicazione piuttosto che scrivere test automatizzati dell'interfaccia utente per quelli esistenti.

Quando l'applicazione cresce, diventa sempre più dispendioso in termini di tempo "toccare questi pulsanti" manualmente ogni volta che si aggiorna l'applicazione.

Ma cosa accadrebbe se ci fosse un framework che semplificasse i test dell'interfaccia utente e non ti desse alcuna scusa per non scrivere test dell'interfaccia utente per le tue app?

Incontra Calabash.

Calabash: test di accettazione automatizzato per app mobili

Circa un anno fa, ho iniziato a cercare un framework di test che fosse facile da usare per le persone che non sono sviluppatori di software. Ed è allora che ho trovato Calabash.

Questo framework di test open source, sviluppato e gestito dal team di Xamarin, funziona sia per Android che per iOS. Ti consente di scrivere ed eseguire test di accettazione automatizzati per applicazioni mobili.

I test di accettazione sono generalmente ciò che viene dopo i test di sistema che determinano se l'app soddisfa i requisiti aziendali. Dato che opera a livello di interfaccia utente, funziona bene come la nostra scelta di framework di automazione dei test dell'interfaccia utente.

Calabash può interagire con la tua app come Espresso o XCTest. Tuttavia, ciò che rende Calabash una scelta eccellente qui è il suo supporto per Cucumber.

Cucumber è uno strumento in grado di eseguire test automatizzati scritti in un inglese semplice (se lo desideri puoi modificarlo per utilizzare qualsiasi altro linguaggio semplice). Quindi, per scrivere test automatici su Cucumber, il tester non ha bisogno di conoscere Java, Objective-C o qualsiasi altro linguaggio di programmazione.

Cosa fa spuntare la zucca?

Il framework Calabash è costituito da librerie che possono interagire con le app Android e iOS. Può essere eseguito su dispositivi reali. Quindi può fare cose che il tester sta facendo manualmente.

Ci sono due diversi progetti su GitHub che rendono possibile Calabash:

• calabash-android - per Android

• calabash-ios - per iOS

Calabash può funzionare con qualsiasi framework di test basato su Ruby. In questo articolo tratteremo il cetriolo, il modo più popolare e conveniente per scrivere test per Calabash.

Prima di continuare, se vuoi provare Calabash mentre segui il resto dell'articolo, assicurati di aver installato Ruby sul tuo computer. Puoi trovare istruzioni dettagliate per l'installazione qui.

Quindi, installa Calabash per la tua piattaforma preferita seguendo i collegamenti GitHub sopra.

Scrivere il tuo primo test su Calabash

Scrivere test su Calabash è abbastanza facile. Vediamo come appare un semplice test per un'app iOS:

 Feature: User Login Scenario: Unsuccessful user login Given the app has launched Then I wait for the "Login" button to appear When I enter "tstuser" into the "Username" field And I enter "qwerty" into the "Password" field And I touch "Login" Then I should see "Username you entered is incorrect" Scenario: Successful user login Given the app has launched Then I wait for the "Login" button to appear When I enter "testeruser" into the "Username" field And I enter "qwerty" into the "Password" field And I touch "Login" Then I should see "Hey testeruser!"

Qui, un'app viene testata con nome utente e password errati, quindi viene testata con nome utente e password corretti. Il test prevede che l'app non riesca ad accedere per il primo scenario, ma che riesca nel secondo.

Puoi creare tutti gli scenari di cui hai bisogno e tutto ciò che devi fare è suddividere i passaggi/istruzioni in semplici frasi inglesi. Proprio come scriveresti una storia!

Chiunque conosca lo sviluppo guidato dal comportamento (BDD) si troverà già a conoscenza di questo.

Come funziona la zucca?

Per vedere cosa succede dietro i passaggi utilizzati dal tester, puoi aprire il progetto su GitHub e controllare il seguente file:

 calabash-cucumber/features/step_definitions/calabash_steps.rb

Vediamo una definizione del passaggio seguente:

 When I enter "testeruser" into the "Username" field

 Then /^I enter "([^\"]*)" into the "([^\"]*)" field$/ do |text_to_type, field_name| touch("textField marked: '#{field_name}'") wait_for_keyboard keyboard_enter_text text_to_type sleep(STEP_PAUSE) end

Questo piccolo frammento di codice Ruby cerca un campo specifico, lo tocca, attende che appaia la tastiera, digita il testo dalla variabile text_to_type e attende un po' prima di passare al passaggio successivo.

La prima parola del passaggio può essere "Dato", "Quando", "Allora", "E" o "Ma". Non importa quale parola chiave utilizzerai. Puoi usarne uno qualsiasi per rendere la storia più chiara.

Come aggiungere passaggi personalizzati

Se hai bisogno di un passaggio che non è ancora implementato in Calabash, puoi scriverlo da solo. La sintassi è esattamente la stessa dei passaggi già predefiniti.

Ad esempio, se un tester deve accedere al campo di input tramite segnaposto, invece del nome del campo:

 Then /^I enter "([^\"]*)" into the field with placeholder "([^\"]*)"$/ do |text_to_type, placeholder| touch("textField placeholder:'#{placeholder}'") wait_for_keyboard() keyboard_enter_text text_to_type sleep(STEP_PAUSE) end

Questa definizione di passaggio è più o meno la stessa della precedente, ma stai accedendo al campo tramite un segnaposto anziché il nome del campo. Dato l'aspetto della tua app, questo potrebbe rendere le cose ancora più facili per il tester.

Ed è facile anche per lo sviluppatore. Lo sviluppatore sta implementando il passaggio una volta, quindi il tester lo utilizza ogni volta che ne ha bisogno. Inoltre, non è necessario conoscere molto Ruby per implementare i propri passaggi personalizzati.

Puoi trovare le funzioni Ruby che puoi utilizzare qui:

http://www.rubydoc.info/gems/calabash-cucumber/Calabash/Cucumber

Xamarin Test Cloud

C'è un'altra sfida quando si testano le applicazioni mobili. Dovresti testarli su quanti più dispositivi possibile, perché ci sono così tanti dispositivi e così tante versioni del sistema operativo.

È qui che Xamarin Test Cloud aiuta molto. Ci sono circa 2.000 dispositivi reali nel cloud e la buona notizia è che supporta i test di Calabash.

Gli stessi test di Calabash che ti hanno aiutato a risparmiare tempo risparmiandoti dal lavoro ripetitivo possono ora essere utilizzati per testare la tua applicazione su molti dispositivi reali.

Inizia a scrivere test dell'interfaccia utente

Se Calabash è la soluzione di test di cui la tua app ha bisogno, con i vantaggi che porta, non lascia spazio a scuse quando si tratta di scrivere test automatizzati dell'interfaccia utente per le tue app mobili. Calabash potrebbe non essere all'altezza se la tua app fa molto affidamento su determinate funzionalità del dispositivo (ad esempio, la fotocamera), ma rende comunque molto più semplice scrivere test per la maggior parte delle app.