30 / 06 / 2017 Developers

Automatyczne testy aplikacji mobilnych cz.3

NA CZYM POLEGA PISANIE TESTÓW AUTOMATYCZNYCH?

Dla wielu osób spoza środowiska IT systemy informatyczne biorą się jakby “z powietrza”. Świetnie pokazuje to następujący schemat:

Źródło: https://thenextweb.com/wp-content/blogs.dir/1/files/2009/10/13449_full.jpg

Tak samo jest w przypadku testów automatycznych. Za każdym testem stoi pewna historia (user story). Następnie przekłada się ona na listę kolejnych działań w aplikacji. Działania przekładają się z kolei na “kliknięcia przycisków”. Na podstawie tych kliknięć możemy tworzyć testy automatyczne. Czy to oznacza, że możemy tylko testować za pomocą kliknięć? Oczywiście, że nie. Wprawdzie niektóre narzędzia ograniczają się tylko do tego, ale testy mogą sprawdzać zachowanie aplikacji również w sytuacjach, na które użytkownik nie miał bezpośredniego wpływu. Przykładem takiego testu może być sprawdzenie co się stanie jak do użytkownika zadzwoni telefon podczas używania aplikacji.

NARZĘDZIA

Na rynku jest wiele dostępnych narzędzi wspomagających pisanie i uruchamianie testów automatycznych. Należą do nich między innymi:

  • Appium – narzędzie opensourcowe, które pozwala na automatyzację aplikacji natywnych, webowych oraz hybrydowych,
  • UIAutomator – framework Googla, który pozwala na testowanie natywnych aplikacji (od API 18) oraz daje dostęp do procesów systemowych,
  • Robotium – który również przeznaczony jest do testowania natywnych (Android) i hybrydowych aplikacji. Cytując oficjalny profil projektu na GitHubie: “Pozwala w prosty sposób na pisanie potężnych testów typu black-box”.

Część narzędzi do testów automatycznych to po prostu biblioteki do języków programowania. W przypadku Androida są to biblioteki javowe. Pozostałe narzędzia umożliwiają nagrywanie zachowania – ruchu na ekranie, a następnie odtworzenie go w ramach testów. Wróćmy jednak do pierwszej grupy. Wyobraźmy sobie, że mamy aplikację z logowaniem. Mamy pewną testową parę loginu i hasła – te dane posłużą nam do sprawdzenia testu. Nasz widok składa się z dwóch pól EditText i przycisku zaloguj. Jak wygląda test logowania np. w Robotium?

public class LoginActivityTest extends ActivityInstrumentationTestCase2<LoginActivity> {
 
   private Solo solo;
 
   public LoginActivityTest() {
       super(LoginActivity.class);
   }
 
   public void setUp() throws Exception {
       solo = new Solo(getInstrumentation(), getActivity());
   }
 
   public void testLogIn() throws Exception {
 
       solo.enterText(0,"login");
       solo.enterText(1,"password");
       solo.clickOnButton("Zaloguj");
 
       Assert.assertTrue(solo.searchText("Logowanie pomyślne"));
 
   }
 
   @Override
   public void tearDown() throws Exception {
       solo.finishOpenedActivities();
   }
 
}

Analogicznie możemy i nawet powinniśmy napisać test, który sprawdzi czy w przypadku błędnego hasła – logowanie się nie powiodło. Dobre praktyki w testowaniu to jednak temat na oddzielny artykuł. Jest pełna dowolność w tworzeniu testów automatycznych. Można testować każdy ekran osobno – dzięki czemu bardzo szybko można “przemielić” ekran, na którym coś przestało działać. W przypadku testów manualnych należałoby przygotować osobne apk, żeby ograniczyć do minimum ilość kliknięć potrzebnych do sprawdzenia wszystkich kombinacji.

TESTY, A GOOGLE

Nie tak dawno na łamach naszego forum opisywaliśmy jak podłączyć się do Firebase. Zachęcam do zapoznania się jeszcze raz z artykułem. Przybliżę teraz inne narzędzie z tej konsoli, a mianowicie Test Lab.

Firebase umożliwia uruchamianie własnych testów, napisanych z użyciem którejś z bibliotek. Aby to zrobić musimy wpierw spakować apk z aplikacją oraz osobne apk z testami. Następnie należy umieścić oba pliki na serwerze, wybrać docelowe urządzenia do przetestowania, a po zakończeniu wykonania testów otrzymamy wyniki. W przypadku aplikacji natywnych możemy również uruchomić test Robo. Taki test uruchamia naszą aplikację w formie drzewa i sprawdza wszystkie ścieżki, do których może dotrzeć.

W darmowym planie można wykonać 10 testów dziennie. Nie jest to dużo, ale na indywidualne potrzeby i szybkie reagowanie powinno wystarczyć. Nawet taka mała ilość przydaje się, gdy otrzymamy powiadomienie (też z Firebase), o błędzie u któregoś z użytkowników. Sam Firebase oprócz przechwytywania zdefiniowanych błędów i komunikatów, zbiera również informacje o nieprzewidzianych błędach. Korzystając z zapisanej zawartości stosu jesteśmy w stanie znaleźć wadliwy ekran i uruchomić testy dla tego ekranu – i to wszystko bez zaawansowanej infrastruktury szybkiego reagowania.

EPILOG

Testy automatyczne mogą budzić kontrowersje, w szczególności ze względu na wyższy koszt wdrożenia. Nie mniej jednak stosując zdrowy rozsądek, można zyskać dzięki zwiększeniu jakości kodu i stosunku pokrycia go testami.

Zachęcam Was do sprawdzenia samemu “z czym to się je”. Ze swojej strony nie będę pisał, że któreś narzędzie jest lepsze lub gorsze, ponieważ to zależy od tego w czym wam się najwygodniej pisze. I pamiętajcie, że dobre testy pisze się z przyjemnością, a nie z przymusu 🙂

FacebookTwitterGoogle+LinkedIn