Diversi framework di automazione dei test per le app React Native

L'asticella è alta per le app mobili di oggi. Innanzitutto, le app devono soddisfare gli standard di qualità che si aspettano i mercati delle app. In secondo luogo, gli utenti di app mobili sono molto esigenti. Sono disponibili molte alternative per il download, quindi gli utenti non tollereranno un'app buggy. Poiché le app mobili sono diventate una parte così cruciale della vita delle persone, gli utenti non saranno timidi nel condividere il loro amore o odio per un'app e quel feedback arriva di fronte a milioni di utenti in pochi secondi.

Ulteriori letture su Smashing:

• Costruisci la tua prima app iOS con JavaScript
• Perché dovresti considerare React Native per la tua app mobile
• Automazione dei test per app, giochi e Web mobile
• Rendering lato server con React, Node ed Express
• Note sull'accessibilità resa dal client

Il cellulare è più importante che mai. Ma ottenere un'app giusta, farla funzionare su tutti i dispositivi possibili, con diverse versioni del sistema operativo, risoluzioni dello schermo, chipset e altre caratteristiche hardware e rendere l'esperienza utente fluida in tutte le possibili configurazioni, è un compito impegnativo.

Sono disponibili un sacco di fantastiche tecnologie, strumenti, framework e componenti open source per la creazione di app mobili native. Quale valore apporta React Native alla scena e come possiamo assicurarci che le app create con esso siano ben accolte dal pubblico di destinazione?

In questo articolo, esamineremo ciò che è disponibile per testare le app React Native. Per prima cosa, spiegherò alcune caratteristiche chiave di React Native, prima di vedere come implementare questi test. In secondo luogo, classificherò metodi e framework di test su tre livelli (unità, integrazione, funzionale), fornendo esempi per ciascuno. Infine, fornirò semplici esempi di come implementare i test utilizzando i framework di automazione dei test open source più diffusi per il test funzionale delle app.

L'architettura di base delle app React Native

Tutto è iniziato con React più di tre anni fa, quando Facebook ha introdotto il suo framework agli sviluppatori web. Era destinato a diventare popolare, non solo perché è stato creato e sviluppato da Facebook, ma anche per le funzionalità che ha fornito agli sviluppatori web e soprattutto per il modo in cui ha cambiato il modo in cui costruiamo le app.

Il concetto di questo tipo di framework "impara una volta, scrivi ovunque" non era nuovo, però; avevamo già visto le librerie JavaScript fare cose simili (Sencha, PhoneGap e Appcelerator, tra gli altri), ma c'era qualcosa di meglio in React che ha avuto un impatto sulle abitudini degli sviluppatori e su come scompongono l'interfaccia utente di un'applicazione in componenti discreti.

React Native non utilizza il DOM per il rendering. Al contrario, esegue il rendering con visualizzazioni dell'interfaccia utente native, il che significa che stai utilizzando i componenti nativi forniti dal sistema operativo. Questo tipo di flusso di creazione del prodotto, in cui si sostituisce l'API DOM con un'API più dichiarativa, offre agli sviluppatori un livello di astrazione più coerente e semplificato.

La cosa fondamentale di React Native è che porta il modello di programmazione React nelle app mobili, nello sviluppo e nei test. In realtà non funziona direttamente come strumento o framework multipiattaforma, ma accelera la tendenza alla creazione di app mobili su questa nuova piattaforma. E questo è uno dei capisaldi di ciò che rende React Native così potente, facile da imparare e facile da scrivere su questa nuova piattaforma.

La principale differenza, oltre al vantaggio, dei dispositivi mobili nativi rispetto al Web è che, invece di eseguire un'implementazione basata su JavaScript in un browser ed esporre elementi HTML, ora ci affidiamo a JavaScriptCore incorporato nelle app, che ottengono specifiche della piattaforma Elementi dell'interfaccia utente.

Test di automazione su diversi livelli: unità, integrazione, componente e funzionale

Tutto il software mobile è costruito utilizzando la composizione. Su Android e iOS, ciò significa che i piccoli componenti software sono organizzati insieme per formare componenti più grandi e di livello superiore con maggiori funzionalità, fino a quando gli obiettivi e i requisiti dell'applicazione non sono stati soddisfatti. Una buona pratica di test consiste nell'eseguire test che coprano la funzionalità a tutti i livelli della composizione.

In questo articolo tratterò metodi di test e framework di automazione a tre livelli. L'obiettivo principale è il test funzionale di livello più alto, ma le app React Native possono essere testate (e i test possono essere automatizzati) almeno ai seguenti livelli:

• Test unitario
  Questo potrebbe essere anche semplice come testare oggetti e metodi JavaScript a livello di componente.
• Test dei componenti
  Ogni componente può essere testato sia visivamente che funzionalmente. ReactTestUtils fornisce un framework semplice per testare i componenti React.
• Test d'integrazione
  Il test di integrazione viene dopo ed è una fase in cui un gruppo di unità diverse viene in genere testato come entità.
• Prove funzionali
  Il test funzionale è un tipo di test black-box che si concentra sui requisiti e sulle interazioni dell'utente e copre tutto il software sottostante, tutte le interazioni dell'utente e l'applicazione come entità.

Oltre a ReactTestUtils, React Native fornisce utili metodi di unit test, ma nessuno di essi copre completamente la logica effettiva dell'applicazione. Pertanto, le app mobili basate su React Native beneficiano maggiormente dei test funzionali dell'interfaccia utente. È disponibile una varietà di framework di automazione dei test funzionali e in questo articolo esamineremo alcuni dei più popolari.

Mentre i test delle unità possono essere eseguiti a livello di componente, l'automazione dei test funzionali offre capacità migliori per testare le entità più grandi in un'app React Native. Con React Native, il test delle unità logiche dei componenti può essere eseguito in isolamento, utilizzando le librerie JavaScript tradizionali e forzando React Native a restituire componenti regolari invece di quelli nativi. Con i framework di automazione dei test funzionali, i componenti dell'interfaccia utente fanno parte dell'app e sono facili da testare nel loro insieme.

Separerò questi framework in framework multipiattaforma e framework specifici per piattaforma, come illustrato nella figura seguente.

La parte migliore delle app React Native è che sono completamente native per entrambe le principali piattaforme mobili (Android e iOS). Ciò significa che otteniamo più framework, strumenti e metodi nativi a scopo di test. Esamineremo i framework di automazione dei test funzionali nella sezione seguente intitolata "Utilizzo dei framework di automazione dei test funzionali con le app React Native".

Iniziamo con le capacità di unit test, usando un test JavaScript per illustrare.

Test unitari con Jest e Jasmine

Per impostazione predefinita, React Native fornisce i test Jest per i test unitari e funziona sia per Android che per iOS. Attualmente, la copertura dei test non è perfetta, ma secondo Facebook, in React Native verranno introdotte più funzionalità di unit test e gli utenti possono già crearne di proprie.

Jest utilizza il framework Jasmine basato sul comportamento come base per testare il codice JavaScript. Ogni test case inizia da una chiamata di funzione describe() , in modo simile a come JUnit usa la classe TestCase . La funzione describe() accetta due parametri: la descrizione e il titolo del test case e la funzione da eseguire. La funzione it() include tutti i passaggi del test e (simile a JUnit) fornisce una serie di funzioni expect() .

Ecco un esempio di uno script di test Jasmine per un'applicazione del lettore.

 describe("Player", function() { var player; var song; beforeEach(function() { player = new Player(); song = new Song(); }); it("should be able to play a song", function() { player.play(song); expect(player.currentlyPlayingSong).toEqual(song); //demonstrates use of custom matcher expect(player).toBePlaying(song); }); describe("when song has been paused", function() { beforeEach(function() { player.play(song); player.pause(); }); it("should indicate the song is paused", function() { expect(player.isPlaying).toBeFalsy(); // demonstrates use of 'not' with a custom matcher expect(player).not.toBePlaying(song); }); it("should be possible to resume", function() { player.resume(); expect(player.isPlaying).toBeTruthy(); expect(player.currentlyPlayingSong).toEqual(song); }); }); // demonstrates use of spies to intercept and test method calls it("tells the current song whether the user has made it a favorite", function() { spyOn(song, 'persistFavoriteStatus'); player.play(song); player.makeFavorite(); expect(song.persistFavoriteStatus).toHaveBeenCalledWith(true); }); //demonstrates use of expected exceptions describe("#resume", function() { it("should throw an exception if song is already playing", function() { player.play(song); expect(function() { player.resume(); }).toThrow("song is already playing"); }); }); });

Questo esempio di base mostra come Jasmine può essere utilizzato per testare la funzionalità di un'app, ma mantiene l'attenzione sul test a livello di metodo. Inoltre, React Native fornisce alcune funzionalità di base per testare i componenti integrati. Funziona sia per i componenti nativi che JavaScript e consente la comunicazione tra loro tramite un bridge.

Test d'integrazione

Al momento, i test di integrazione evidenziati nella community di React Native sono disponibili solo per iOS e sono molto limitati nella loro capacità di testare i componenti. La comunicazione passa attraverso il bridge e richiede componenti sia nativi che JavaScript. Per questa funzionalità sono disponibili due componenti per implementare test di integrazione personalizzati, RCTestRunner e RCTestModule.

Un esempio di base di Objective-C per la creazione di uno scheletro di prova di un'app iOS inizierebbe in questo modo:

 @implementation ExampleTests { RCTTestRunner *_runner; } - (void)setUp { [super setUp]; _runner = RCTInitRunnerForApp(@"IntegrationTestHarnessTest", nil); } - void()testExampleTests { [_runner runTest:_cmd module:@"ExampleTests"] } @end

Tuttavia, esistono altri modi per eseguire il test di integrazione ed estenderlo ad Android e iOS. Una buona alternativa per l'esecuzione di test unitari e di integrazione è Mocha, che fornisce un framework di test JavaScript ricco di funzionalità che viene eseguito su Node.js. Mocha fornisce anche interfacce per lo sviluppo basato sul comportamento (BDD), lo sviluppo basato sui test (TDD) e QUnit per i test.

Per i test funzionali dell'interfaccia utente, tratterò i framework di automazione dei test più importanti e utilizzati, inclusi Appium, Calabash, XCTest e pochi altri.

Utilizzo di framework di automazione dei test funzionali con le app React Native

Per semplificare il processo di sviluppo delle app e massimizzare la copertura dei test, disponiamo di numerosi framework di automazione dei test open source tra cui scegliere.

La scelta migliore, se la tua app verrà eseguita su diverse piattaforme del sistema operativo, è un framework che supporta più piattaforme e fornisce una solida base per l'automazione dei test. Nei dispositivi mobili, il termine "multipiattaforma" si riferisce a un framework che fornisce le stesse API, strumenti e funzionalità sia per Android che per iOS.

Inoltre, è disponibile una gamma di ottimi framework specifici per piattaforma. Naturalmente, ogni framework è stato costruito per una particolare piattaforma e, nella maggior parte dei casi, è più facile da adottare per quella piattaforma. Oltre ad Appium e Calabash, in questo articolo tratterò quattro framework specifici della piattaforma: Robotium ed Espresso per Android e XCTest ed EarlGrey per iOS.

Quando si tratta di testare l'automazione, tieni presente che le app create con React Native sono completamente native sia su iOS che su Android; quindi, i framework di automazione dei test funzionali funzioneranno bene con loro.

L'esempio che userò con ogni framework è un'implementazione di un'interfaccia utente di pulsanti di opzione molto semplice.

 <Radio onSelect={this.onSelect.bind(this)} defaultSelect={this.state.optionSelected - 1}> <Option color="black" selectedColor="#000000"> <Item title="First option" description="First radio button"/> </Option> <Option color="black" selectedColor="#000000"> <Item title="Second option" description="Second radio button"/> </Option> <Option color="black" selectedColor="#000000"> <Item title="Third option" description="Third radio button"/> </Option> </Radio>

Lo snippet di test incluso in ogni sezione del framework seguente mostra come lo script di test gestisce ogni elemento dell'interfaccia utente e come vengono gestiti i clic e altri input dell'utente. Lo scopo degli esempi non è fornire istruzioni dettagliate, ma piuttosto confrontare esempi e mostrare ciò che è disponibile oggi per l'automazione dei test e quali linguaggi di programmazione possono essere utilizzati per i test.

Framework multipiattaforma

Come affermato, React Native non è in realtà un framework multipiattaforma, ma l'adozione su altre piattaforme è facile. Nelle prossime due sezioni, esamineremo due popolari framework di automazione dei test multipiattaforma per i test mobili e l'automazione dei test mobili.

Appio

Appium è un framework di automazione dei test open source, con uno strumento di ispezione che funziona bene per app Web native, ibride e mobili. Utilizza JSONWireProtocol internamente per interagire con le app iOS e Android, utilizzando Selenium WebDriver. Per questo motivo, Appium funziona estremamente bene anche per il Web mobile e i casi d'uso sono molto simili se Selenium viene utilizzato per i test Web.

In effetti, nell'ultimo anno Appium è stata una stella nascente nell'automazione dei test mobili. Originariamente, è stato creato per fornire supporto multipiattaforma per entrambe le principali piattaforme, Android e iOS.

Essere multipiattaforma significa che il framework e i suoi script funzionano esattamente allo stesso modo su entrambe le piattaforme. Inoltre, Appium fornisce un fantastico supporto per il linguaggio di programmazione: gli sviluppatori possono scrivere test utilizzando il loro linguaggio preferito (ad esempio, Java, Ruby, Python, C#), strumenti e ambiente. È anche facile iniziare, creare e mantenere test riutilizzabili ed eseguire tali test su dispositivi fisici reali.

Quando si tratta di app basate su React Native, JavaScript non è necessariamente richiesto; i test possono essere scritti in qualsiasi lingua. Ad esempio, gli script di Appium possono assomigliare a questo:

 driver.findElement(By.id("com.example.app:id/radio0")).click(); driver.findElement(By.id("com.example.app:id/radio1")).click(); driver.findElement(By.id("com.example.app:id/radio2")).click(); driver.findElement(By.id("com.example.app:id/editText1")).click(); driver.findElement(By.id("com.example.app:id/editText1")).sendKeys("Simple Test"); driver.findElement(By.name("Answer")).click(); // or alternatively like this: driver.findElement(By.id("com.example.app:id/button1")).click();

Quindi, in che modo queste funzioni di WebDriver accedono alle app in esecuzione sui dispositivi? Fondamentalmente, Appium avvia uno script di test sul dispositivo o emulatore, che quindi crea un server e ascolta i comandi dal server Appium principale. È lo stesso del server Selenium, che riceve richieste HTTP dalle librerie client Selenium. La differenza tra Android e iOS è illustrata nell'immagine qui sotto:

Con iOS, Selenium WebDriver ottiene un comando dallo script Appium (ad esempio, click() ) e lo invia sotto forma di JSON tramite una richiesta HTTP al server Appium. Appium conosce il contesto di automazione e invia questo comando al server dei comandi di Instruments, che attende che il client dei comandi di Instruments lo raccolga e lo esegua con bootstrap.js nell'ambiente iOS Instruments. Una volta eseguito il comando, il client dei comandi di Instruments rimanda il messaggio al server Appium, che registra tutto ciò che riguarda il comando nella sua console. Questo ciclo continua fino al termine dello script di test.

Su Android le cose funzionano quasi allo stesso modo, tranne per il fatto che i framework utilizzati sono Selendroid e UiAutomator. In breve, Appium traduce i comandi WebDriver in comandi UiAutomator (livello API 17 o superiore) o Selendroid (livello API 16 o inferiore). Su un dispositivo fisico, bootstrap.jar avvia un server TCP che riceve i comandi da un client TCP. Il processo è simile su iOS.

Se sei interessato a iniziare con Appium, è disponibile molto materiale, incluse istruzioni dettagliate e tutorial su Appium.

Zucca

Un altro ottimo framework di test multipiattaforma è Calabash, che consente a chiunque di scrivere test per applicazioni mobili. La differenza principale è che i test di Calabash sono scritti in Cucumber. L'idea alla base dell'utilizzo di questo tipo di linguaggio per i test è fantastica: il test stesso è come una specifica e tutti i test sono semplici e facili da leggere ma eseguibili dal sistema di automazione.

Rispetto ad Appium, Calabash offre un modo più semplice per creare test multipiattaforma per Android e iOS. Ciò è dovuto al vocabolario semplice e al linguaggio orientato alle specifiche, che rende i test Calabash identici su entrambe le piattaforme. I test effettivi sono scritti in cetriolino ed eseguiti in cetriolo.

A causa di queste capacità, le differenze tra Calabash che funziona su Android e su applicazioni iOS sono minori. Ancora una volta, non ci sono implicazioni per le app React Native perché tutti i componenti e le interfacce utente sono completamente nativi per queste piattaforme.

Il flusso di test e creazione di test di base, tuttavia, rimane lo stesso. I test Calabash (e Gherkin) comprendono funzionalità, scenari e passaggi. L'approccio consigliato consiste nel completare prima le descrizioni di livello più alto: le funzionalità, quindi gli scenari e quindi i passaggi effettivi. Una buona regola pratica è creare prima le funzionalità di Calabash.

L'esempio seguente mostra come la nostra applicazione e i suoi componenti dell'interfaccia utente (pulsanti di opzione, campo di testo e pulsante) sarebbero implementati in Calabash:

 Feature: Answer the question feature Scenario: As a valid user, I want to answer app question, I wait for text "What is the best way to test application on a hundred devices?" Then I press radio button 0 Then I press radio button 1 Then I press radio button 2 Then I enter text "Simple Test" into field with id "editText1" Then I press view with id "Button1"

I passaggi di solito iniziano con una delle parole chiave given , then , when and o but . Tuttavia, non è necessario; possono invece usare * .

Calabash è anche ampiamente utilizzato dai non sviluppatori e può essere utilizzato per le specifiche e la documentazione del prodotto grazie al suo linguaggio e alla sua logica di facile comprensione. Alla fine, le funzionalità e gli scenari vengono racchiusi nel codice Ruby.

Configurare Calabash e iniziare a lavorarci è facile. Se hai installato Bundler e Ruby (o rbenv), premi queste poche righe nella tua console e presto verrà configurato un ambiente Calabash:

 $ gem install calabash-android $ gem install calabash-cucumber

Questo si occuperà dell'installazione di Calabash-Android e Calabash-iOS e il tuo viaggio con l'automazione dei test può iniziare.

Framework specifici della piattaforma

Quando si tratta di automatizzare i test su app Android e iOS, ci sono alcuni vantaggi nell'utilizzo di framework specifici della piattaforma rispetto a quelli multipiattaforma. Ad esempio, alcuni framework sono costruiti in stretta collaborazione con SDK e IDE, che sono prontamente disponibili mentre un'applicazione è in fase di sviluppo. Diamo un'occhiata ad alcuni esempi di questi tipi di framework per Android e iOS.

Robotium ed ExtSolo (Android)

Robotium è stato uno dei primi framework di test a funzionare per app Android native e ibride. I test dell'interfaccia utente creati con Robotium consentono test funzionali, di sistema e di accettazione dell'utente per le app Android, che abbracciano e gestiscono più attività Android. Infatti, Robotium fornisce supporto per le primissime versioni di Android, a partire dal livello API 8.

Di recente, Robotium è stato esteso con la libreria ExtSolo, che fornisce varie funzioni utili per il test delle app:

• ridimensionamento automatico di x e y clic per qualsiasi risoluzione del display;
• trascinamenti a più percorsi;
• cattura automatica degli screenshot al momento del fallimento del test;
• posizioni fittizie (coordinate GPS);
• cambio della lingua del dispositivo Android;
• controllo della connessione Wi-Fi;

Con il codice Java, i test sono facili da creare utilizzando qualsiasi SDK e IDE Java. La funzione principale utilizzata in questo esempio è findViewById , che trova una vista identificata dall'attributo id . L'elemento dell'interfaccia utente può anche essere identificato da un nome, una classe o qualche altro attributo. Il nostro esempio di codice con un attributo id sarebbe simile a questo:

 solo.clickOnView(solo.findViewById("com.example.app:id/radio0")); solo.clickOnView(solo.findViewById("com.example.app:id/radio1")); solo.clickOnView(solo.findViewById("com.example.app:id/radio2")); solo.enterText((EditText) solo.findViewById("com.example.app:id/editText1"), "Simple Test"); solo.clickOnView(solo.findViewById("com.example.app:id/button1"));

Robotium sta cercando di individuare gli elementi dell'interfaccia utente in base id , alla descrizione e ad altre caratteristiche. Sfortunatamente, questo non è sempre l'approccio migliore e non funziona necessariamente bene con i componenti di visualizzazione web. Tuttavia, con l'aiuto della libreria ExtSolo, gli utenti possono definire clic e altre interazioni sugli elementi dell'interfaccia utente che si adattano alla risoluzione. Inoltre, è possibile codificare le coordinate e queste si ridimensionano quando cambia la risoluzione del display.

Se stai usando Robotium, iniziare con Robotium ExtSolo è facile e senza sforzo. Basta clonare il repository per te stesso e creare la libreria:

 $ git clone https://github.com/bitbar/robotium-extensions $ ant clean instrument

Successivamente, posiziona il file .jar creato di recente nella cartella libs nel tuo progetto Android Studio e assicurati che il tuo progetto sia collegato ad esso. Tutte queste fantastiche funzionalità e servizi aggiuntivi sono ora nel tuo spazio di lavoro.

Espresso (Android)

Il framework di test Espresso fornisce API per la scrittura di test dell'interfaccia utente per simulare le interazioni degli utenti per un'app Android. L'API Espresso è leggera e fornisce tre componenti principali: viewMatchers , viewActions e viewAssertions .

Il bello di Espresso è che fornisce la sincronizzazione automatica dei metodi di prova e degli elementi dell'interfaccia utente che vengono testati. Ad esempio, se lo script di test vuole premere un pulsante ma il pulsante non è ancora visibile sullo schermo, attenderà che questo pulsante possa essere premuto (cioè è visibile e può verificarsi un clic). Ciò rende l'esecuzione del test molto veloce perché nessuno script di test deve includere alcun comando di sospensione o attesa. Inoltre, gli sviluppatori non hanno bisogno di logica aggiuntiva per gestire i problemi relativi ai tempi.

 // R class ID identifier for radio buttons onView(withId(R.id.radio0)).perform(click()); onView(withId(R.id.radio1)).perform(click()); onView(withId(R.id.radio2)).perform(click()); onView(withId(R.id.EditText1)).perform(click()); // Instead of R, we use getIdentifier onView(withId(getInstrumentation().getTargetContext().getResources() .getIdentifier("com.example.app:id/EditText1", null, null))).perform((typeText("Simple Test"))); onView(withId(getInstrumentation().getTargetContext().getResources() .getIdentifier("com.example.app:id/Button1", null, null))).perform(click());

Espresso ha i suoi pro e contro e, a causa dell'API leggera, non sono disponibili molti servizi aggiuntivi o chiamate di funzioni per gli sviluppatori. Ad esempio, è necessario utilizzare metodi alternativi per acquisire schermate, gestire test, generare risultati di test e altro ancora.

Al Google IO 2016 Google ha presentato Espresso Test Recorder come parte integrante di Android Studio. Sebbene la funzione non sia ancora disponibile, varrà sicuramente la pena aspettare.

XCTest e KIF (iOS)

XCTest è strettamente accoppiato con Xcode ma è ancora utilizzabile con dispositivi iOS reali e simulatori. XCTest consente agli sviluppatori di scrivere test per i componenti a qualsiasi livello e fornisce anche un framework per le funzionalità di test dell'interfaccia utente. I test XCTest sono raggruppati in sottoclassi di XCTestCase. Scrivere qualsiasi test con XCTest dovrebbe essere banale per gli sviluppatori iOS perché XCTest è completamente compatibile sia con Objective-C che con Swift.

KIF (abbreviazione di "mantenerlo funzionale") è un framework di test di integrazione iOS strettamente correlato e che utilizza obiettivi di test XCTest. I test KIF possono essere eseguiti direttamente in XCTestCase o in qualsiasi sottoclasse. KIF consente una facile automazione delle applicazioni iOS sfruttando gli attributi di accessibilità che il sistema operativo mette a disposizione delle persone con disabilità visive.

Vediamo come apparirebbero i nostri componenti dell'interfaccia utente con Objective-C:

 - (void)testClicksOnRadioButtons { [tester tapViewWithAccessibilityLabel:@”Radio1”]; [tester tapViewWithAccessibilityLabel:@”Radio2”]; [tester tapViewWithAccessibilityLabel:@”Radio3”]; [tester enterText:@”Simple Test” intoViewWithAccessibilityLabel:@”editText1”]; [tester tapViewWithAccessibilityLabel:@”Answer”]; }

In alternativa, con Swift, il test sarebbe semplice come questo:

 testClicksOnRadioButtons() { let app = XCUIApplication() app.radiobutton[0].tap() app.radiobutton[1].tap() app.radiobutton[2].tap() app.staticTexts[“Simple Test”] app.button[0].tap() }

Si noti che questo pseudocodice di alto livello richiede codice aggiuntivo per funzionare completamente. Se stai cercando ulteriori informazioni su XCTest e in generale sull'utilizzo delle funzionalità di test di Xcode, Apple ti copre.

Earl Grey (iOS)

Era appena all'inizio di quest'anno quando Google ha reso open source il suo framework di test delle app iOS funzionale, chiamato EarlGrey. Essendo utilizzato internamente da Google, ha funzionato relativamente bene con le app iOS native – YouTube, Google Calendar, Google Foto, Google Play Music, solo per citarne alcuni – e ha suscitato un serio interesse. Per iniziare con EarlGrey, avrai bisogno dell'ambiente Xcode installato e delle conoscenze di base dello sviluppo iOS.

Ci sono molte somiglianze tra EarlGrey ed Espresso (sì, entrambi sono sviluppati da Google) e le loro caratteristiche fanno funzionare entrambi i framework ed eseguono test rapidamente. Simile a Espresso, i test EarlGrey aspettano automaticamente gli eventi (animazioni, richieste di rete, ecc.) prima di provare a interagire con l'interfaccia utente. Ciò semplifica la scrittura dei test perché gli sviluppatori non devono preoccuparsi di dormire o attendere i comandi. Inoltre, il codice stesso è più facile da mantenere perché fornisce descrizioni procedurali delle fasi del test.

EarlGrey contiene anche abbinatori disponibili dalla classe GREYMatchers. La documentazione consiglia di utilizzare gli elementi dell'interfaccia utente con i parametri di accessibilità. Per identificare gli elementi dell'interfaccia utente, gli sviluppatori possono utilizzare grey_accessibilityID() o grey_accessibilityLabel() .

 - (void)testBasicSelectionAndAction { [[EarlGrey selectElementWithMatcher::grey_accessibilityID(@"ClickHere")] performAction:grey_tap()]; // Example of long press with EarlGrey matchers - (void)testLongPress { [[EarlGrey selectElementWithMatcher::grey_accessibilityLabel(@"Box")] performAction:grey_longPressWithDuration(0.5f)]; [[EarlGrey selectElementWithMatcher::grey_accessibilityLabel(@"One Long Press")] assertWithMatcher:grey_sufficientlyVisible()]; // Example of multi-select, visible click on items - (void)testCollectionMatchers { id visibleSendButtonMatcher = grey_allOf(grey_accessibilityID(@"Box"), grey_sufficientlyVisible(), nil); [[EarlGrey selectElementWithMatcher:visibleSendButtonMatcher] performAction:grey_tap()]; }

Simile a XCTest, la nostra implementazione dei pulsanti di opzione non è così semplice e i pulsanti per XCTest dovrebbero essere definiti come UIElements supportati da iOS per abilitare i clic e le interazioni dell'utente.

Conclusione

Abbiamo trattato le basi delle applicazioni React Native e come possono essere testate utilizzando vari metodi e framework. Questo si verifica abbastanza spesso, ma gli standard del settore per l'automazione dei test mobili a livello di interfaccia utente funzionale funzioneranno sulle app React Native proprio come fanno con qualsiasi altra app nativa. I framework di automazione dei test che abbiamo trattato qui sono ampiamente utilizzati per app mobili native, app ibride, Web mobile e app React Native.

In sintesi, determinare il linguaggio di programmazione su cui è costruita un'applicazione mobile non è fondamentale perché non avrà alcuna influenza sui framework di automazione dei test con cui può essere testata. Come discusso, oggi sono disponibili molti potenti framework di automazione dei test, con i quali le app React Native funzioneranno quando racchiuse come APK o IPA.

Cosa stai usando per il test dell'app React Native? Pesare con un commento qui sotto!