Cadre diverse de testare-automatizare pentru aplicațiile native React

Stacheta este ridicată pentru aplicațiile mobile de astăzi. În primul rând, aplicațiile trebuie să îndeplinească standardul de calitate la care se așteaptă piețele de aplicații. În al doilea rând, utilizatorii de aplicații mobile sunt foarte pretențioși. Sunt disponibile o mulțime de alternative pentru descărcare, astfel încât utilizatorii nu vor tolera o aplicație cu erori. Deoarece aplicațiile mobile au devenit o parte atât de esențială a vieții oamenilor, utilizatorii nu vor fi sfiați să-și împărtășească dragostea sau ura față de o aplicație – iar acest feedback ajunge în fața milioanelor de utilizatori în câteva secunde.

Citiri suplimentare despre Smashing:

• Creați-vă prima aplicație iOS cu JavaScript
• De ce ar trebui să luați în considerare React Native pentru aplicația dvs. mobilă
• Testați automatizarea pentru aplicații, jocuri și web mobil
• Redare pe server cu React, Node și Express
• Note despre accesibilitatea redată de client

Mobilul este mai important ca niciodată. Dar obținerea unei aplicații corecte, funcționarea ei pe toate dispozitivele posibile, cu diferite versiuni de sistem de operare, rezoluții de afișare, chipset-uri și alte caracteristici hardware și asigurarea unei experiențe de utilizator fluide în toate configurațiile posibile este o sarcină dificilă.

O mulțime de tehnologii excelente, instrumente, cadre și componente open-source sunt disponibile pentru construirea de aplicații mobile native. Ce valoare aduce React Native pe scena și cum ne putem asigura că aplicațiile create cu acesta sunt bine primite de publicul țintă?

În acest articol, vom analiza ce este disponibil pentru testarea aplicațiilor React Native. Mai întâi, voi explica câteva caracteristici cheie ale React Native, înainte de a vedea cum să implementez aceste teste. În al doilea rând, voi clasifica metodele și cadrele de testare pe trei niveluri (unitate, integrare, funcțional), oferind exemple pentru fiecare. În cele din urmă, voi oferi exemple simple de implementare a testelor folosind cele mai populare cadre de automatizare a testelor open-source pentru testarea funcțională a aplicațiilor.

Arhitectura de bază a aplicațiilor React Native

Totul a început cu React în urmă cu mai bine de trei ani, când Facebook și-a prezentat cadrul pentru dezvoltatorii web. Era neapărat să fie popular, nu doar pentru că a fost creat și dezvoltat de Facebook, ci și datorită capacităților pe care le-a oferit dezvoltatorilor web – și mai ales a modului în care a schimbat modul în care construim aplicații.

Conceptul acestui tip de cadru „învață o dată, scrie oriunde” nu era totuși nou; am văzut deja bibliotecile JavaScript făcând lucruri similare (Sencha, PhoneGap și Appcelerator, printre altele), dar ceva a fost mai bun la React, care a avut un impact asupra obiceiurilor dezvoltatorilor și asupra modului în care aceștia descompun interfața de utilizare a unei aplicații în componente discrete.

React Native nu folosește DOM-ul pentru randare. În schimb, se redă cu vizualizări native ale UI, ceea ce înseamnă că utilizați componentele native furnizate de sistemul de operare. Acest tip de flux de creare a produselor, în care înlocuiți API-ul DOM cu un API mai declarativ, oferă dezvoltatorilor un nivel de abstractizare mai coeziv și simplificat.

Principalul lucru despre React Native este că aduce modelul de programare React în aplicațiile mobile, dezvoltare și testare. De fapt, nu funcționează direct ca instrument sau cadru multiplatform, dar accelerează tendința de a construi aplicații mobile pe această nouă platformă. Și aceasta este una dintre pietrele de temelie a ceea ce face React Native atât de puternic, ușor de învățat și ușor de scris pe această nouă platformă.

Diferența majoră, precum și avantajul dintre mobilul nativ față de web este că, în loc să rulăm o implementare bazată pe JavaScript într-un browser și să expunem elemente HTML, acum ne bazăm pe JavaScriptCore încorporat în aplicații, care sunt specifice platformei. Elemente UI.

Testați automatizarea la diferite niveluri: unitate, integrare, componente și funcțional

Toate software-urile mobile sunt construite folosind compoziție. Pe Android și iOS, aceasta înseamnă că componentele software mici sunt aranjate împreună pentru a forma componente mai mari, de nivel superior, cu o funcționalitate mai mare, până când obiectivele și cerințele aplicației au fost îndeplinite. O bună practică de testare este să rulați teste care să acopere funcționalitatea la toate nivelurile compoziției.

În acest articol, voi acoperi metodele de testare și cadrele de automatizare la trei niveluri. Accentul principal este pe cel mai înalt nivel, testarea funcțională, dar aplicațiile React Native pot fi testate - iar testarea poate fi automatizată - cel puțin la următoarele niveluri:

• Testarea unitară
  Acest lucru ar putea fi chiar la fel de simplu ca testarea obiectelor și metodelor JavaScript la nivel de componentă.
• Testarea componentelor
  Fiecare componentă poate fi testată fie vizual, fie funcțional. ReactTestUtils oferă un cadru simplu pentru testarea componentelor React.
• Testare de integrare
  Urmează testarea integrării și este o fază în care un grup de unități diferite sunt de obicei testate ca entitate.
• Testare funcțională
  Testarea funcțională este un tip de testare cutie neagră care se concentrează pe cerințele și interacțiunile utilizatorului și acoperă toate programele subiacente, toate interacțiunile utilizatorului și aplicația ca entitate.

Pe lângă ReactTestUtils, React Native oferă metode utile de testare unitară, dar niciuna dintre ele nu acoperă în detaliu logica reală a aplicației. Prin urmare, aplicațiile mobile construite pe React Native beneficiază mai mult de testarea funcțională a UI. Sunt disponibile o varietate de cadre funcționale de testare și automatizare și ne vom uita la câteva dintre cele mai populare în acest articol.

În timp ce testarea unitară se poate face la nivel de componentă, automatizarea testelor funcționale oferă capabilități mai bune pentru testarea entităților mai mari într-o aplicație React Native. Cu React Native, testarea unității logice a componentelor se poate face izolat, folosind biblioteci JavaScript tradiționale și forțând React Native să returneze componente obișnuite în loc de cele native. Cu cadre funcționale de testare și automatizare, componentele UI fac parte din aplicație și sunt ușor de testat în ansamblu.

Voi separa aceste cadre în cadre multiplatforme și cadre specifice platformei, așa cum este ilustrat în imaginea de mai jos.

Cea mai bună parte a aplicațiilor React Native este că sunt complet native pentru ambele platforme mobile majore (Android și iOS). Aceasta înseamnă că obținem mai multe cadre, instrumente și metode native în scopuri de testare. Ne vom uita la cadrele funcționale de automatizare a testelor în secțiunea de mai jos intitulată „Utilizarea cadrelor funcționale de automatizare a testelor cu aplicații React Native”.

Să începem cu capabilitățile de testare unitară, folosind un test JavaScript pentru a ilustra.

Testarea unitară cu Jest și Jasmine

În mod implicit, React Native oferă teste Jest pentru testarea unitară, iar acest lucru funcționează atât pentru Android, cât și pentru iOS. În prezent, acoperirea testelor nu este perfectă, dar conform Facebook, mai multe capabilități de testare unitară vor fi introduse în React Native, iar utilizatorii își pot construi deja propriile capacități.

Jest folosește cadrul bazat pe comportamentul Jasmine ca bază pentru testarea codului JavaScript. Fiecare caz de testare începe de la un apel al funcției describe() , similar cu modul în care JUnit utilizează clasa TestCase . Funcția describe() are doi parametri: descrierea și titlul cazului de testare și funcția care trebuie executată. Funcția it() include toți pașii de testare și (similar cu JUnit) oferă o serie de funcții expect() .

Iată un exemplu de script de testare Jasmine pentru o aplicație de jucător.

 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"); }); }); });

Acest exemplu de bază arată cum poate fi folosită Jasmine pentru a testa funcționalitatea unei aplicații, dar se concentrează pe testarea la nivel de metodă. În plus, React Native oferă câteva capabilități de bază pentru testarea componentelor integrate. Acest lucru funcționează atât pentru componentele native, cât și pentru JavaScript și permite comunicarea între ele printr-o punte.

Testare de integrare

În acest moment, testele de integrare evidențiate în comunitatea React Native sunt disponibile doar pentru iOS și sunt foarte limitate în capacitatea lor de a testa componente. Comunicarea trece prin bridge și necesită atât componente native, cât și JavaScript. Pentru această funcționalitate, sunt disponibile două componente pentru a implementa teste de integrare personalizate, RCTestRunner și RCTestModule.

Un exemplu de bază Objective-C pentru construirea unui schelet de testare al unei aplicații iOS ar începe astfel:

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

Cu toate acestea, există și alte modalități de a rula testarea integrării și de a le extinde la Android și iOS. O alternativă bună pentru rularea atât a testelor unitare, cât și a celor de integrare este Mocha, care oferă un cadru de testare JavaScript bogat în funcții, care rulează pe Node.js. Mocha oferă, de asemenea, dezvoltare bazată pe comportament (BDD), dezvoltare condusă prin testare (TDD) și interfețe QUnit pentru testare.

Pentru testarea UI funcțională, voi acoperi cele mai proeminente și mai utilizate cadre de automatizare a testelor, inclusiv Appium, Calabash, XCTest și câteva altele.

Utilizarea cadrelor funcționale de testare-automatizare cu aplicații React Native

Pentru a eficientiza procesul de dezvoltare a aplicațiilor și pentru a maximiza acoperirea testării, avem numeroase cadre open-source de automatizare a testelor din care să alegem.

Cea mai bună alegere – dacă aplicația dvs. va rula pe mai multe platforme de sistem de operare – este un cadru care acceptă mai multe platforme și oferă o bază solidă pentru automatizarea testelor. În mobil, termenul „multiplatformă” se referă la un cadru care oferă aceleași API, instrumente și capabilități atât pentru Android, cât și pentru iOS.

În plus, sunt disponibile o serie de cadre grozave specifice platformei. Desigur, fiecare cadru a fost construit pentru o anumită platformă și, în majoritatea cazurilor, este mai ușor de adoptat pentru platforma respectivă. Pe lângă Appium și Calabash, voi acoperi patru cadre specifice platformei în acest articol: Robotium și Espresso pentru Android și XCTest și EarlGrey pentru iOS.

Când vine vorba de testarea automatizării, rețineți că aplicațiile create cu React Native sunt complet native atât pe iOS, cât și pe Android; prin urmare, cadrele funcționale de testare-automatizare vor funcționa bine cu ele.

Exemplul pe care îl voi folosi cu fiecare cadru este o implementare a unei interfețe de utilizare pentru buton radio foarte de bază.

 <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>

Fragmentul de testare inclus în fiecare secțiune a cadrului de mai jos arată cum se ocupă scriptul de testare cu fiecare element al interfeței de utilizare și cum sunt gestionate clicurile și alte intrări ale utilizatorului. Scopul exemplelor nu este de a oferi instrucțiuni pas cu pas, ci mai degrabă de a compara exemple și de a arăta ce este disponibil pentru automatizarea testelor astăzi și ce limbaje de programare pot fi folosite pentru testare.

Cadre multiplatforme

După cum sa menționat, React Native nu este de fapt un cadru multiplatform, dar adoptarea acestuia pe alte platforme este ușoară. În următoarele două secțiuni, vom trece prin două cadre populare de automatizare a testelor pe mai multe platforme pentru testarea mobilă și automatizarea testelor mobile.

Appium

Appium este un cadru de testare-automatizare open-source, cu un instrument de inspecție care funcționează bine pentru aplicațiile web native, hibride și mobile. Utilizează JSONWireProtocol intern pentru a interacționa cu aplicațiile iOS și Android, folosind Selenium WebDriver. Din acest motiv, Appium funcționează extrem de bine și pentru web-ul mobil, iar cazurile de utilizare sunt foarte asemănătoare dacă Selenium este folosit pentru testarea web.

De fapt, Appium a fost o stea în ascensiune în automatizarea testelor mobile în ultimul an. Inițial, a fost construit pentru a oferi suport multiplatform pentru ambele platforme majore, Android și iOS.

A fi multiplatformă înseamnă că cadrul și scripturile sale funcționează exact la fel pe ambele platforme. În plus, Appium oferă suport fantastic pentru limbajul de programare — dezvoltatorii pot scrie teste folosind limbajul lor preferat (de exemplu, Java, Ruby, Python, C#), instrumente și mediu. De asemenea, este ușor să începeți, să creați și să mențineți teste reutilizabile și să executați acele teste pe dispozitive fizice reale.

Când vine vorba de aplicații React Native, JavaScript nu este neapărat necesar; testele pot fi scrise în orice limbă. De exemplu, scripturile Appium pot arăta astfel:

 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();

Deci, cum accesează aceste funcții WebDriver aplicațiile care rulează pe dispozitive? Practic, Appium pornește un script de testare pe dispozitiv sau emulator, care apoi creează un server și ascultă comenzile de la serverul principal Appium. Este același cu serverul Selenium, care primește solicitări HTTP de la bibliotecile client Selenium. Diferența dintre Android și iOS este ilustrată în imaginea de mai jos:

Cu iOS, Selenium WebDriver primește o comandă din scriptul Appium (de exemplu, click() ) și o trimite sub formă de JSON printr-o solicitare HTTP către serverul Appium. Appium cunoaște contextul de automatizare și trimite această comandă către serverul de comandă Instruments, care așteaptă ca clientul de comandă Instruments să o preia și să o execute cu bootstrap.js în mediul iOS Instruments. Odată ce comanda este executată, clientul de comandă Instruments trimite mesajul înapoi către serverul Appium, care înregistrează tot ce are legătură cu comandă în consola sa. Acest ciclu continuă până la terminarea scriptului de testare.

Pe Android, lucrurile funcționează aproape la fel, cu excepția faptului că cadrele folosite sunt Selendroid și UiAutomator. Pe scurt, Appium traduce comenzile WebDriver în comenzi UiAutomator (nivel API 17 sau mai mare) sau Selendroid (nivel API 16 sau mai mic). Pe un dispozitiv fizic, bootstrap.jar lansează un server TCP care primește comenzi de la un client TCP. Procesul este similar pe iOS.

Dacă sunteți interesat să începeți cu Appium, sunt disponibile o mulțime de materiale, inclusiv instrucțiuni pas cu pas și tutoriale Appium.

Calabash

Un alt cadru excelent de testare multiplatformă este Calabash, care permite oricui să scrie teste pentru aplicații mobile. Principala diferență este că testele Calabash sunt scrise în Castravete. Ideea din spatele utilizării acestui tip de limbaj pentru teste este minunată: testul în sine este ca o specificație și toate testele sunt simple și ușor de citit, dar executabile de sistemul de automatizare.

În comparație cu Appium, Calabash oferă o modalitate mai ușoară de a crea teste pe mai multe platforme pentru Android și iOS. Acest lucru se datorează vocabularului simplu și limbajului orientat pe specificații, ceea ce face ca testele Calabash să fie identice pe ambele platforme. Testele propriu-zise sunt scrise în Gherkin și rulează în Castravete.

Datorită acestor capacități, diferențele dintre Calabash care lucrează pe Android și pe aplicațiile iOS sunt minore. Din nou, nu există nicio implicație pentru aplicațiile React Native, deoarece toate componentele și interfețele de utilizator sunt complet native pentru aceste platforme.

Cu toate acestea, fluxul de testare de bază și de creare a testelor rămâne același. Testele Calabash (și Gherkin) cuprind caracteristici, scenarii și pași. Abordarea recomandată este să finalizați mai întâi descrierile de cel mai înalt nivel: caracteristici, urmate de scenarii și apoi pașii efectivi. O regulă de bază bună este să creați mai întâi caracteristicile Calabash.

Exemplul de mai jos arată cum ar fi implementate aplicația noastră și componentele sale UI (butoane radio, câmp de text și buton) în 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"

Pașii încep de obicei cu unul dintre cuvintele cheie given , then , when and sau but . Cu toate acestea, nu trebuie; pot folosi * în schimb.

Calabash este, de asemenea, utilizat pe scară largă de către non-dezvoltatori și poate fi folosit pentru specificațiile și documentația produsului datorită limbajului și logicii sale ușor de înțeles. În cele din urmă, caracteristicile și scenariile sunt împachetate în cod Ruby.

Configurarea Calabash și începerea lucrului cu el sunt ușoare. Dacă aveți instalate Bundler și Ruby (sau rbenv), apăsați doar aceste câteva rânduri în consola dvs. și în curând va fi configurat un mediu Calabash:

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

Acest lucru se va ocupa de instalarea Calabash-Android și Calabash-iOS, iar călătoria dvs. cu automatizarea testului poate începe.

Cadre specifice platformei

Când vine vorba de automatizarea testelor pe aplicațiile Android și iOS, există anumite avantaje în utilizarea cadrelor specifice platformei față de cele multiplatforme. De exemplu, unele cadre sunt construite îndeaproape de SDK-uri și IDE-uri, care sunt ușor disponibile în timp ce o aplicație este în curs de dezvoltare. Să ne uităm la câteva exemple de aceste tipuri de cadre pentru Android și iOS.

Robotium și ExtSolo (Android)

Robotium a fost unul dintre primele cadre de testare care a funcționat pentru aplicațiile Android native și hibride. Testele UI create cu Robotium permit teste funcționale, de sistem și de acceptare a utilizatorului pentru aplicațiile Android, care acoperă și gestionează mai multe activități Android. De fapt, Robotium oferă suport pentru versiuni foarte timpurii de Android, începând de la nivelul API 8.

Recent, Robotium a fost extins cu biblioteca ExtSolo, care oferă diverse funcții utile pentru testarea aplicațiilor:

• scalarea automată a clicurilor x și y pentru orice rezoluție de afișare;
• trageri cu mai multe căi;
• captura automată a capturii de ecran în momentul eșecului testului;
• locații simulate (coordonate GPS);
• schimbarea limbii dispozitivului Android;
• controlul conexiunii Wi-Fi;

Cu codul Java, testele sunt ușor de construit folosind orice SDK și IDE Java. Funcția principală folosită în acest exemplu este findViewById , care găsește o vizualizare care este identificată prin atributul id . Elementul UI poate fi identificat și printr-un nume, clasă sau alt atribut. Exemplul nostru de cod cu un atribut id ar arăta astfel:

 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 încearcă aici să localizeze elementele UI pe baza id , descriere și alte caracteristici. Din păcate, aceasta nu este întotdeauna cea mai bună abordare și nu funcționează neapărat bine cu componentele webview. Cu toate acestea, cu ajutorul bibliotecii ExtSolo, utilizatorii pot defini clicuri și alte interacțiuni pe elementele UI care se scalează odată cu rezoluția. De asemenea, coordonatele hardcoding sunt posibile, iar acestea se scalează atunci când rezoluția afișajului se modifică.

Dacă utilizați Robotium, atunci începeți cu Robotium ExtSolo este ușor și fără efort. Doar clonează depozitul pentru tine și construiește biblioteca:

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

După aceasta, plasați fișierul .jar construit recent în folderul libs din proiectul dvs. Android Studio și asigurați-vă că proiectul este conectat la acesta. Toate aceste funcții și servicii suplimentare grozave sunt acum în spațiul dvs. de lucru.

Espresso (Android)

Cadrul de testare Espresso oferă API-uri pentru scrierea testelor UI pentru a simula interacțiunile utilizatorului pentru o aplicație Android. API-ul Espresso este ușor și oferă trei componente principale: viewMatchers , viewActions și viewAssertions .

Frumusețea Espresso este că oferă sincronizarea automată a metodelor de testare și a elementelor UI care sunt testate. De exemplu, dacă scriptul de testare dorește să apese un buton, dar butonul nu este încă vizibil pe ecran, va aștepta până când acest buton poate fi apăsat (adică este vizibil și se poate face un clic). Acest lucru face ca execuția testului să fie foarte rapidă, deoarece niciun script de testare nu trebuie să includă comenzi de repaus sau de așteptare. De asemenea, dezvoltatorii nu au nevoie de logică suplimentară pentru a gestiona problemele legate de sincronizare.

 // 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 are propriile sale avantaje și dezavantaje și, datorită API-ului ușor, nu sunt disponibile pentru dezvoltatori multe servicii suplimentare sau apeluri de funcții. De exemplu, trebuie să utilizați metode alternative pentru a face capturi de ecran, a gestiona teste, a scoate rezultatele testelor și multe altele.

La Google IO 2016, Google a introdus Espresso Test Recorder ca parte integrantă a Android Studio. Deși funcția nu este încă disponibilă, cu siguranță va merita așteptarea.

XCTest și KIF (iOS)

XCTest este strâns cuplat cu Xcode, dar este încă utilizabil atât cu dispozitive iOS reale, cât și cu simulatoare. XCTest permite dezvoltatorilor să scrie teste pentru componente la orice nivel și oferă, de asemenea, un cadru pentru capabilitățile de testare a UI. Testele XCTest sunt grupate în subclase de XCTestCase. Scrierea oricăror teste cu XCTest ar trebui să fie banală pentru dezvoltatorii iOS, deoarece XCTest este pe deplin compatibil atât cu Objective-C, cât și cu Swift.

KIF (prescurtare de la „keep it functional”) este un cadru de testare a integrării iOS care este strâns legat de și care utilizează ținte de testare XCTest. Testele KIF pot fi executate direct în XCTestCase sau în orice subclasă. KIF permite automatizarea ușoară a aplicațiilor iOS prin valorificarea atributelor de accesibilitate pe care sistemul de operare le pune la dispoziție celor cu dizabilități vizuale.

Să vedem cum ar arăta componentele noastre UI cu Objective-C:

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

Alternativ, cu Swift, testul ar arăta la fel de simplu ca acesta:

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

Rețineți că acest pseudo-cod de nivel înalt necesită cod suplimentar pentru a funcționa pe deplin. Dacă căutați mai multe informații despre XCTest și, în general, despre utilizarea capacităților de testare Xcode, Apple vă acoperă.

EarlGrey (iOS)

Tocmai la începutul acestui an, Google și-a deschis cadru de testare funcțional pentru aplicații iOS, numit EarlGrey. Fiind folosit intern de Google, a funcționat relativ bine cu aplicațiile native iOS - YouTube, Google Calendar, Google Photos, Google Play Music, pentru a numi câteva - și a stârnit un interes serios. Pentru a începe cu EarlGrey, veți avea nevoie de instalarea mediului Xcode și de cunoștințe de bază despre dezvoltarea iOS.

Există o mulțime de asemănări între EarlGrey și Espresso (da, ambele sunt dezvoltate de Google), iar caracteristicile lor fac ca ambele cadre să funcționeze și să execute teste rapid. Similar cu Espresso, testele EarlGrey așteaptă automat evenimente (animații, solicitări de rețea etc.) înainte de a încerca să interacționeze cu interfața de utilizare. Acest lucru facilitează scrierea testelor, deoarece dezvoltatorii nu trebuie să-și facă griji cu privire la comenzile de somn sau așteptare. În plus, codul în sine este mai ușor de întreținut deoarece oferă descrieri procedurale ale pașilor de testare.

EarlGrey conține, de asemenea, potriviri care sunt disponibile din clasa GREYMatchers. Documentația recomandă utilizarea elementelor UI cu parametrii de accesibilitate. Pentru a identifica elementele UI, dezvoltatorii pot folosi grey_accessibilityID() sau 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()]; }

Similar cu XCTest, implementarea butonului radio nu este atât de simplă, iar butoanele pentru XCTest ar trebui definite ca elemente UIE acceptate de iOS pentru a permite clicurile și interacțiunile utilizatorilor.

Concluzie

Am acoperit elementele de bază ale aplicațiilor React Native și cum pot fi testate folosind diferite metode și cadre. Acest lucru apare destul de des, dar standardele din industrie pentru automatizarea testelor mobile la nivel de interfață funcțională vor funcționa pe aplicațiile React Native la fel ca și cu orice alte aplicații native. Cadrele de testare-automatizare pe care le-am acoperit aici sunt utilizate pe scară largă pentru aplicațiile mobile native, aplicațiile hibride, webul mobil, precum și aplicațiile React Native.

În rezumat, determinarea limbajului de programare pe care este construită o aplicație mobilă nu este critică, deoarece nu va avea nicio influență asupra cadrelor de testare-automatizare cu care poate fi testată. După cum sa discutat, astăzi sunt disponibile o mulțime de cadre puternice de automatizare a testelor, cu care aplicațiile React Native vor funcționa atunci când sunt împachetate ca APK sau IPA.

Ce folosiți pentru testarea aplicației React Native? Cântărește cu un comentariu mai jos!