Różnorodne frameworki do automatyzacji testów dla aplikacji natywnych React

Poprzeczka jest ustawiona wysoko dla dzisiejszych aplikacji mobilnych. Po pierwsze, aplikacje muszą spełniać standardy jakości, jakich oczekują rynki aplikacji. Po drugie, użytkownicy aplikacji mobilnych są bardzo wymagający. Dostępnych jest wiele alternatyw do pobrania, więc użytkownicy nie będą tolerować wadliwej aplikacji. Ponieważ aplikacje mobilne stały się tak istotną częścią życia ludzi, użytkownicy nie będą się wstydzić dzielić swoją miłość lub nienawiść do aplikacji — a ta opinia dociera do milionów użytkowników w ciągu kilku sekund.

Dalsza lektura na temat rozbijania:

• Tworzenie pierwszej aplikacji na iOS z JavaScript
• Dlaczego powinieneś rozważyć React Native dla swojej aplikacji mobilnej
• Automatyzacja testów aplikacji, gier i sieci mobilnej
• Renderowanie po stronie serwera za pomocą React, Node i Express
• Uwagi dotyczące dostępności renderowanej przez klienta

Mobilność jest ważniejsza niż kiedykolwiek. Jednak uzyskanie odpowiedniej aplikacji, sprawienie, aby działała na wszystkich możliwych urządzeniach, z różnymi wersjami systemu operacyjnego, rozdzielczościami wyświetlania, chipsetami i innymi cechami sprzętowymi, a także sprawienie, by wrażenia użytkownika były płynne we wszystkich możliwych konfiguracjach, to trudne zadanie.

Dostępnych jest mnóstwo świetnych technologii, narzędzi, frameworków i komponentów open source do tworzenia natywnych aplikacji mobilnych. Jaką wartość wnosi React Native na scenę i jak możemy upewnić się, że aplikacje zbudowane na jego podstawie są dobrze odbierane przez docelowych odbiorców?

W tym artykule przyjrzymy się, co jest dostępne do testowania aplikacji React Native. Najpierw wyjaśnię kilka kluczowych cech React Native, zanim przyjrzę się, jak wdrożyć te testy. Po drugie, podzielę metody testowania i frameworki na trzy poziomy (jednostka, integracja, funkcjonalność), podając przykłady dla każdego. Na koniec przedstawię proste przykłady implementacji testów przy użyciu najpopularniejszych frameworków do automatyzacji testów o otwartym kodzie źródłowym do funkcjonalnego testowania aplikacji.

Podstawowa architektura aplikacji natywnych React

Wszystko zaczęło się od Reacta ponad trzy lata temu, kiedy Facebook przedstawił swój framework twórcom stron internetowych. Musiała być popularna, nie tylko dlatego, że została stworzona i stworzona przez Facebooka, ale ze względu na możliwości, jakie zapewniała programistom internetowym — a zwłaszcza to, jak zmieniła sposób, w jaki tworzymy aplikacje.

Koncepcja tego typu frameworka „naucz się raz, pisz gdziekolwiek” nie była jednak nowa; widzieliśmy już, jak biblioteki JavaScript robią podobne rzeczy (m.in. Sencha, PhoneGap i Appcelerator), ale w React było coś lepszego, co miało wpływ na nawyki programistów i sposób, w jaki rozkładają interfejs użytkownika aplikacji na oddzielne komponenty.

React Native nie używa DOM do renderowania. Zamiast tego renderuje z natywnymi widokami interfejsu użytkownika, co oznacza, że ​​używasz natywnych komponentów dostarczanych przez system operacyjny. Ten rodzaj przepływu tworzenia produktu, w którym zastępujesz API DOM bardziej deklaratywnym API, zapewnia programistom bardziej spójny i uproszczony poziom abstrakcji.

Kluczową rzeczą w React Native jest to, że wprowadza model programowania React do aplikacji mobilnych, rozwoju i testowania. W rzeczywistości nie działa bezpośrednio jako wieloplatformowe narzędzie lub framework, ale przyspiesza trend tworzenia aplikacji mobilnych na tej nowej platformie. I to jest jeden z fundamentów tego, co sprawia, że ​​React Native jest tak potężny, łatwy do nauczenia i łatwy do pisania na tej nowej platformie.

Główna różnica, a także zaleta natywnej wersji mobilnej w porównaniu z siecią, polega na tym, że zamiast uruchamiać implementację opartą na JavaScript w przeglądarce i eksponować elementy HTML, teraz polegamy na osadzonym JavaScriptCore w aplikacjach, które są zależne od platformy Elementy interfejsu użytkownika.

Automatyzacja testów na różnych poziomach: jednostkowy, integracyjny, komponentowy i funkcjonalny

Całe oprogramowanie mobilne jest budowane przy użyciu kompozycji. W systemach Android i iOS oznacza to, że małe komponenty oprogramowania są ułożone razem, tworząc większe, wyższego poziomu komponenty o większej funkcjonalności, dopóki cele i wymagania aplikacji nie zostaną spełnione. Dobrą praktyką testowania jest uruchamianie testów obejmujących funkcjonalność na wszystkich poziomach kompozycji.

W tym artykule omówię metody testowania i frameworki automatyzacji na trzech poziomach. Główny nacisk kładzie się na testowanie funkcjonalne na najwyższym poziomie, ale aplikacje React Native można testować — a testowanie można zautomatyzować — na co najmniej następujących poziomach:

• Testów jednostkowych
  Może to być nawet tak proste, jak testowanie obiektów i metod JavaScript na poziomie komponentów.
• Testowanie komponentów
  Każdy element można przetestować wizualnie lub funkcjonalnie. ReactTestUtils zapewnia prosty framework do testowania komponentów React.
• Testy integracyjne
  Kolejnym etapem jest testowanie integracyjne, które jest fazą, w której grupa różnych jednostek jest zwykle testowana jako jednostka.
• Testy funkcjonalności
  Testowanie funkcjonalne to rodzaj testowania czarnoskrzynkowego, który koncentruje się na wymaganiach i interakcjach użytkownika i obejmuje całe oprogramowanie, wszystkie interakcje użytkownika oraz aplikację jako całość.

Oprócz ReactTestUtils, React Native zapewnia przydatne metody testowania jednostkowego, ale żadna z nich nie pokrywa w pełni rzeczywistej logiki aplikacji. Dlatego aplikacje mobilne zbudowane na React Native odnoszą większe korzyści z testowania funkcjonalnego interfejsu użytkownika. Dostępnych jest wiele funkcjonalnych frameworków do automatyzacji testów, a w tym artykule przyjrzymy się kilku najpopularniejszym z nich.

Podczas gdy testy jednostkowe można wykonać na poziomie komponentów, automatyzacja testów funkcjonalnych zapewnia lepsze możliwości testowania większych jednostek w aplikacji React Native. Dzięki React Native testowanie jednostek logiki komponentów może odbywać się w izolacji, przy użyciu tradycyjnych bibliotek JavaScript i zmuszając React Native do zwracania zwykłych komponentów zamiast natywnych. Dzięki funkcjonalnym strukturom automatyzacji testów, komponenty interfejsu użytkownika są częścią aplikacji i są łatwe do przetestowania jako całość.

Podzielę te frameworki na frameworki międzyplatformowe i frameworki specyficzne dla platformy, jak pokazano na poniższym obrazku.

Najlepszą częścią aplikacji React Native jest to, że są one w pełni natywne dla obu głównych platform mobilnych (Android i iOS). Oznacza to, że otrzymujemy więcej frameworków, narzędzi i natywnych metod do celów testowych. Przyjrzymy się ramom automatyzacji testów funkcjonalnych w sekcji poniżej zatytułowanej „Korzystanie ze struktur automatyzacji testów funkcjonalnych z aplikacjami natywnymi React”.

Zacznijmy od możliwości testowania jednostkowego, używając do zilustrowania testu JavaScript.

Testowanie jednostkowe z Jest i Jasmine

Domyślnie React Native udostępnia testy Jest do testowania jednostkowego i działa to zarówno na Androidzie, jak i na iOS. Obecnie zasięg testów nie jest doskonały, ale według Facebooka w React Native zostanie wprowadzonych więcej możliwości testowania jednostkowego, a użytkownicy mogą już tworzyć własne.

Jest używa struktury opartej na zachowaniu Jasmine jako podstawy do testowania kodu JavaScript. Każdy przypadek testowy zaczyna się od wywołania funkcji define describe() , podobnie jak JUnit używa klasy TestCase . Funkcja description describe() przyjmuje dwa parametry: opis i tytuł przypadku testowego oraz funkcję do wykonania. Funkcja it() obejmuje wszystkie etapy testu i (podobnie jak JUnit) udostępnia serię funkcji expect() .

Oto przykład skryptu testowego Jasmine dla aplikacji odtwarzacza.

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

Ten podstawowy przykład pokazuje, jak Jasmine może być używany do testowania funkcjonalności aplikacji, ale skupia się na testowaniu na poziomie metody. Ponadto React Native zapewnia podstawowe możliwości testowania zintegrowanych komponentów. Działa to zarówno w przypadku komponentów natywnych, jak i JavaScript oraz umożliwia komunikację między nimi za pośrednictwem mostu.

Testy integracyjne

W tej chwili testy integracyjne wyróżnione w społeczności React Native są dostępne tylko dla iOS i mają bardzo ograniczone możliwości testowania komponentów. Komunikacja przechodzi przez most i wymaga zarówno komponentów natywnych, jak i JavaScript. Dla tej funkcjonalności dostępne są dwa komponenty do implementacji niestandardowych testów integracyjnych: RCTestRunner i RCTestModule.

Podstawowy przykład Objective-C do budowania szkieletu testowego aplikacji na iOS zaczynałby się tak:

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

Istnieją jednak inne sposoby uruchamiania testów integracji i rozszerzenia ich na systemy Android i iOS. Dobrą alternatywą dla przeprowadzania testów jednostkowych i integracyjnych jest Mocha, który zapewnia bogaty w funkcje framework testowy JavaScript działający na Node.js. Mocha zapewnia również programowanie sterowane zachowaniem (BDD), programowanie sterowane testami (TDD) i interfejsy Qunit do testowania.

Jeśli chodzi o testowanie funkcjonalnego interfejsu użytkownika, omówię najbardziej znane i najczęściej używane frameworki do automatyzacji testów, w tym Appium, Calabash, XCTest i kilka innych.

Używanie frameworków do automatyzacji testów funkcjonalnych z aplikacjami natywnymi React

Aby usprawnić proces tworzenia aplikacji i zmaksymalizować zasięg testowania, mamy do wyboru wiele platform automatyzacji testów typu open source.

Najlepszym wyborem — jeśli Twoja aplikacja będzie działać na kilku platformach operacyjnych — jest platforma obsługująca wiele platform i zapewniająca solidną podstawę do automatyzacji testów. W przypadku urządzeń mobilnych termin „wieloplatformowy” odnosi się do struktury, która zapewnia ten sam interfejs API, narzędzia i możliwości zarówno dla systemu Android, jak i iOS.

Ponadto dostępny jest szereg świetnych platform specyficznych dla platformy. Oczywiście każda platforma została stworzona dla konkretnej platformy i w większości przypadków jest łatwiejsza do zaadaptowania dla tej platformy. Oprócz Appium i Calabash omówię w tym artykule cztery platformy specyficzne dla platformy: Robotium i Espresso dla Androida oraz XCTest i EarlGrey dla iOS.

Jeśli chodzi o automatyzację testów, pamiętaj, że aplikacje zbudowane za pomocą React Native są w pełni natywne zarówno na iOS, jak i Androida; w związku z tym funkcjonalne struktury automatyzacji testów będą z nimi współpracować.

Przykład, którego użyję z każdym frameworkiem, to implementacja bardzo podstawowego interfejsu użytkownika z przyciskami radiowy.

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

Fragment testowy zawarty w każdej sekcji frameworka poniżej pokazuje, jak skrypt testowy radzi sobie z każdym elementem interfejsu użytkownika oraz jak obsługiwane są kliknięcia i inne dane wejściowe użytkownika. Celem przykładów nie jest dostarczenie instrukcji krok po kroku, ale raczej porównanie przykładów i pokazanie, co jest obecnie dostępne dla automatyzacji testów i jakich języków programowania można użyć do testowania.

Platformy międzyplatformowe

Jak już wspomniano, React Native nie jest w rzeczywistości platformą wieloplatformową, ale wdrożenie jej na innych platformach jest łatwe. W następnych dwóch sekcjach omówimy dwa popularne międzyplatformowe frameworki automatyzacji testów do testowania mobilnego i automatyzacji testów mobilnych.

Appium

Appium to platforma automatyzacji testów typu open source z narzędziem do inspekcji, które działa dobrze w przypadku natywnych, hybrydowych i mobilnych aplikacji internetowych. Wykorzystuje wewnętrznie JSONWireProtocol do interakcji z aplikacjami na iOS i Androida za pomocą Selenium WebDriver. Z tego powodu Appium działa bardzo dobrze również w sieci mobilnej, a przypadki użycia są bardzo podobne, jeśli Selenium jest używane do testowania sieci.

W rzeczywistości Appium było wschodzącą gwiazdą w automatyzacji testów mobilnych w ciągu ostatniego roku. Pierwotnie został zbudowany w celu zapewnienia wieloplatformowej obsługi obu głównych platform, Androida i iOS.

Wieloplatformowość oznacza, że ​​framework i jego skrypty działają dokładnie tak samo na obu platformach. Ponadto Appium zapewnia fantastyczną obsługę języka programowania — programiści mogą pisać testy w swoim ulubionym języku (na przykład Java, Ruby, Python, C#), narzędziach i środowisku. Łatwo jest również rozpocząć, tworzyć i utrzymywać testy wielokrotnego użytku oraz wykonywać te testy na rzeczywistych urządzeniach fizycznych.

Jeśli chodzi o aplikacje oparte na React Native, JavaScript nie jest koniecznie wymagany; testy mogą być napisane w dowolnym języku. Na przykład skrypty Appium mogą wyglądać tak:

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

Jak więc te funkcje WebDriver uzyskują dostęp do aplikacji działających na urządzeniach? Zasadniczo Appium uruchamia testowy skrypt na urządzeniu lub emulatorze, który następnie tworzy serwer i nasłuchuje poleceń z głównego serwera Appium. Jest taki sam jak serwer Selenium, który pobiera żądania HTTP z bibliotek klienta Selenium. Różnicę między Androidem a iOS ilustruje poniższy obrazek:

W systemie iOS Selenium WebDriver pobiera polecenie ze skryptu Appium (na przykład click() ) i wysyła je w postaci JSON za pośrednictwem żądania HTTP do serwera Appium. Appium zna kontekst automatyzacji i wysyła to polecenie do serwera poleceń Instruments, który czeka, aż klient poleceń Instruments je odbierze i wykona za pomocą bootstrap.js w środowisku iOS Instruments. Po wykonaniu polecenia klient poleceń Instruments wysyła wiadomość z powrotem do serwera Appium, który rejestruje wszystko, co jest związane z poleceniem w swojej konsoli. Ten cykl trwa aż do zakończenia skryptu testowego.

Na Androidzie wszystko działa prawie tak samo, z wyjątkiem tego, że używane frameworki to Selendroid i UiAutomator. Krótko mówiąc, Appium tłumaczy polecenia WebDriver na polecenia UiAutomator (poziom API 17 lub wyższy) lub Selendroid (poziom API 16 lub niższy). Na urządzeniu fizycznym plik bootstrap.jar uruchamia serwer TCP, który otrzymuje polecenia od klienta TCP. Proces jest podobny na iOS.

Jeśli jesteś zainteresowany rozpoczęciem pracy z Appium, dostępnych jest wiele materiałów, w tym instrukcje krok po kroku i samouczki dotyczące Appium.

Tykwa

Inną świetną platformą do testowania międzyplatformowego jest Calabash, która umożliwia każdemu pisanie testów dla aplikacji mobilnych. Główną różnicą jest to, że testy Calabash są napisane w Cucumber. Idea używania tego rodzaju języka do testów jest niesamowita: sam test jest jak specyfikacja, a wszystkie testy są proste i łatwe do odczytania, a jednocześnie możliwe do wykonania przez system automatyzacji.

W porównaniu z Appium, Calabash zapewnia łatwiejszy sposób tworzenia testów międzyplatformowych dla systemów Android i iOS. Wynika to z prostego słownictwa i języka zorientowanego na specyfikację, co sprawia, że ​​testy Calabash są identyczne na obu platformach. Rzeczywiste testy są napisane w Korniszu i prowadzone w Ogórku.

Ze względu na te możliwości różnice między Calabash działającym na Androidzie a aplikacjami na iOS są niewielkie. Ponownie, nie ma to wpływu na aplikacje React Native, ponieważ wszystkie komponenty i interfejsy użytkownika są w pełni natywne dla tych platform.

Jednak podstawowy przepływ testowania i tworzenia testów pozostaje taki sam. Testy Calabash (i Gherkin) obejmują funkcje, scenariusze i kroki. Zalecanym podejściem jest wypełnienie najpierw opisów najwyższego poziomu: funkcji, następnie scenariuszy, a następnie rzeczywistych kroków. Dobrą zasadą jest utworzenie najpierw funkcji Calabash.

Poniższy przykład pokazuje, jak nasza aplikacja i jej elementy interfejsu użytkownika (przyciski radiowe, pole tekstowe i przycisk) zostałyby zaimplementowane w 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"

Kroki zwykle zaczynają się od jednego z given słów kluczowych , then , when and lub but . Jednak nie muszą; mogą zamiast tego użyć * .

Calabash jest również szeroko stosowany przez osoby nie będące programistami i może być używany do specyfikacji produktów i dokumentacji ze względu na łatwy do zrozumienia język i logikę. Ostatecznie funkcje i scenariusze są opakowane w kod Ruby.

Konfigurowanie Calabash i rozpoczęcie pracy z nim jest łatwe. Jeśli masz zainstalowany Bundler i Ruby (lub rbenv), po prostu naciśnij te kilka linii w konsoli, a wkrótce zostanie skonfigurowane środowisko Calabash:

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

To zajmie się instalacją Calabash-Android i Calabash-iOS, a Twoja podróż z automatyzacją testów może się rozpocząć.

Platformy specyficzne dla platformy

Jeśli chodzi o automatyzację testów w aplikacjach na Androida i iOS, istnieją pewne zalety korzystania z platform specyficznych dla platformy w porównaniu z platformami wieloplatformowymi. Na przykład niektóre frameworki są zbudowane blisko SDK i IDE, które są łatwo dostępne, gdy aplikacja jest w fazie rozwoju. Przyjrzyjmy się kilku przykładom tego typu frameworków dla Androida i iOS.

Robotium i ExtSolo (Android)

Robotium było jednym z pierwszych frameworków testowych, które działały z natywnymi i hybrydowymi aplikacjami na Androida. Testy interfejsu użytkownika stworzone za pomocą Robotium umożliwiają testy funkcjonalne, systemowe i akceptacyjne dla aplikacji na Androida, obejmujące i obsługujące wiele działań na Androida. W rzeczywistości Robotium zapewnia wsparcie dla bardzo wczesnych wersji Androida, począwszy od poziomu API 8.

Ostatnio Robotium zostało rozszerzone o bibliotekę ExtSolo, która zapewnia różne przydatne funkcje do testowania aplikacji:

• automatyczne skalowanie kliknięć x i y dla dowolnej rozdzielczości wyświetlania;
• przeciąganie wielościeżkowe;
• automatyczne przechwytywanie zrzutów ekranu w momencie niepowodzenia testu;
• symulowane lokalizacje (współrzędne GPS);
• zmiana języka urządzenia z Androidem;
• kontrola połączenia Wi-Fi;

Dzięki kodowi Java testy są łatwe do zbudowania przy użyciu dowolnego Java SDK i IDE. Podstawową funkcją użytą w tym przykładzie jest findViewById , która znajduje widok identyfikowany przez atrybut id . Element UI może być również identyfikowany przez nazwę, klasę lub inny atrybut. Nasz przykładowy kod z atrybutem id wyglądałby tak:

 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 próbuje tutaj zlokalizować elementy interfejsu użytkownika na podstawie id , opisu i innych cech. Niestety nie zawsze jest to najlepsze podejście i niekoniecznie działa dobrze z komponentami webview. Jednak za pomocą biblioteki ExtSolo użytkownicy mogą definiować kliknięcia i inne interakcje na elementach interfejsu użytkownika, które skalują się wraz z rozdzielczością. Możliwe jest również zakodowanie współrzędnych, które skalują się, gdy zmienia się rozdzielczość wyświetlania.

Jeśli korzystasz z Robotium, rozpoczęcie pracy z Robotium ExtSolo jest łatwe i bezproblemowe. Po prostu sklonuj repozytorium dla siebie i zbuduj bibliotekę:

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

Następnie umieść ostatnio utworzony plik .jar w folderze libs w projekcie Android Studio i upewnij się, że projekt jest z nim połączony. Wszystkie te wspaniałe dodatkowe funkcje i usługi są teraz dostępne w Twoim obszarze roboczym.

Espresso (Android)

Platforma testowa Espresso udostępnia interfejsy API do pisania testów interfejsu użytkownika w celu symulowania interakcji użytkownika w aplikacji na Androida. Espresso API jest lekki i zawiera trzy główne komponenty: viewMatchers , viewActions i viewAssertions .

Piękno Espresso polega na tym, że zapewnia automatyczną synchronizację metod testowych i elementów interfejsu użytkownika, które są testowane. Na przykład, jeśli skrypt testowy chce nacisnąć przycisk, ale przycisk nie jest jeszcze widoczny na ekranie, poczeka, aż ten przycisk będzie można nacisnąć (tzn. będzie widoczny i może nastąpić kliknięcie). To sprawia, że ​​wykonywanie testów jest bardzo szybkie, ponieważ żadne skrypty testowe nie muszą zawierać żadnych poleceń uśpienia lub czekania. Ponadto programiści nie potrzebują dodatkowej logiki do obsługi problemów związanych z czasem.

 // 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 ma swoje plusy i minusy, a ze względu na lekkie API programiści nie mają do dyspozycji wielu dodatkowych usług lub wywołań funkcji. Na przykład musisz użyć alternatywnych metod do robienia zrzutów ekranu, zarządzania testami, wyników testów i nie tylko.

Na Google IO 2016 Google przedstawił Espresso Test Recorder jako integralną część Android Studio. Chociaż funkcja nie jest jeszcze dostępna, na pewno warto na nią poczekać.

XCTest i KIF (iOS)

XCTest jest ściśle powiązany z Xcode, ale nadal można go używać zarówno z prawdziwymi urządzeniami iOS, jak i symulatorami. XCTest umożliwia programistom pisanie testów komponentów na dowolnym poziomie, a także zapewnia ramy dla możliwości testowania interfejsu użytkownika. Testy XCTest są pogrupowane w podklasy XCTestCase. Pisanie jakichkolwiek testów za pomocą XCTest powinno być trywialne dla programistów iOS, ponieważ XCTest jest w pełni kompatybilny zarówno z Objective-C, jak i Swiftem.

KIF (skrót od „zachowaj funkcjonalność”) to platforma testów integracji systemu iOS, która jest ściśle powiązana z celami testowymi XCTest i korzysta z nich. Testy KIF można wykonywać bezpośrednio w XCTestCase lub dowolnej podklasie. KIF umożliwia łatwą automatyzację aplikacji iOS poprzez wykorzystanie atrybutów dostępności, które system operacyjny udostępnia osobom z niepełnosprawnością wzroku.

Zobaczmy, jak wyglądałyby nasze komponenty interfejsu użytkownika z Objective-C:

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

Alternatywnie, w przypadku Swifta, test wyglądałby tak prosto, jak poniżej:

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

Zauważ, że ten pseudokod wysokiego poziomu wymaga dodatkowego kodu, aby w pełni funkcjonować. Jeśli szukasz więcej informacji na temat XCTest i ogólnie na temat korzystania z możliwości testowania Xcode, Apple Cię obejmuje.

EarlGrey (iOS)

Dopiero na początku tego roku Google udostępnił na zasadach open source swoją funkcjonalną platformę testowania aplikacji na iOS o nazwie EarlGrey. Używany wewnętrznie przez Google, działał stosunkowo dobrze z natywnymi aplikacjami na iOS – YouTube, Kalendarz Google, Zdjęcia Google, Muzyka Google Play, żeby wymienić tylko kilka – i wzbudził poważne zainteresowanie. Aby rozpocząć korzystanie z EarlGrey, potrzebujesz zainstalowanego środowiska Xcode i podstawowej wiedzy na temat programowania na iOS.

Istnieje wiele podobieństw między EarlGrey i Espresso (tak, oba zostały opracowane przez Google), a ich cechy sprawiają, że oba frameworki działają i szybko wykonują testy. Podobnie jak Espresso, testy EarlGrey automatycznie czekają na zdarzenia (animacje, żądania sieciowe itp.) przed próbą interakcji z interfejsem użytkownika. Ułatwia to pisanie testów, ponieważ programiści nie muszą martwić się o polecenia uśpienia lub oczekiwania. Ponadto sam kod jest łatwiejszy w utrzymaniu, ponieważ zawiera proceduralne opisy kroków testowych.

EarlGrey zawiera również elementy dopasowujące, które są dostępne z klasy GREYMatchers. Dokumentacja zaleca używanie elementów UI z parametrami dostępności. Aby zidentyfikować elementy interfejsu użytkownika, programiści mogą użyć grey_accessibilityID() lub 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()]; }

Podobnie jak w przypadku XCTest, nasza implementacja przycisku radiowego nie jest tak prosta, a przyciski XCTest powinny być zdefiniowane jako elementy UIElement obsługiwane przez system iOS, aby umożliwić kliknięcia i interakcje użytkownika.

Wniosek

Omówiliśmy podstawy aplikacji React Native i sposoby ich testowania przy użyciu różnych metod i frameworków. Pojawia się to dość często, ale standardy branżowe dotyczące automatyzacji testów mobilnych na poziomie funkcjonalnego interfejsu użytkownika będą działać w aplikacjach React Native tak samo, jak w przypadku innych aplikacji natywnych. Struktury automatyzacji testów, które tutaj omówiliśmy, są szeroko stosowane w natywnych aplikacjach mobilnych, aplikacjach hybrydowych, mobilnej sieci Web, a także w aplikacjach React Native.

Podsumowując, określenie języka programowania, na którym zbudowana jest aplikacja mobilna, nie jest krytyczne, ponieważ nie będzie miało żadnego wpływu na frameworki automatyzacji testów, z którymi można ją przetestować. Jak wspomniano, obecnie dostępnych jest wiele potężnych frameworków do automatyzacji testów, z którymi aplikacje React Native będą współpracować po zapakowaniu jako APK lub IPA.

Czego używasz do testowania aplikacji React Native? Zważ z komentarzem poniżej!