Testowanie interfejsu użytkownika na Androida i iOS za pomocą Calabash

Testowanie jest istotną częścią każdego procesu tworzenia aplikacji mobilnych. Niezależnie od tego, czy automatyzujesz takie testy, czy nie, żaden rozsądny programista nie uważa swojej pracy za wykonaną, chyba że przetestował swoją aplikację.

Dobrze przetestowana aplikacja zwykle przechodzi przez wiele etapów testowania: testy jednostkowe, testy integracyjne, testy akceptacyjne i tak dalej. Wraz z rozwojem aplikacji rośnie znaczenie testowania, a automatyzacja testowania staje się koniecznością.

Podczas gdy inne platformy, takie jak sieć, znacznie się rozwinęły pod względem mechanizmów testowych i frameworków, sfera mobilna nie pozostaje w tyle. W tym artykule dowiesz się, jak wykorzystać Calabash do zautomatyzowania interfejsu użytkownika aplikacji na Androida i iOS za pomocą prostych instrukcji w języku angielskim i sprawić, by testy akceptacyjne były tak bezbolesne, jak to tylko możliwe.

Na czym polega testowanie interfejsu użytkownika?

Jeśli testujesz swoje aplikacje ręcznie, prawdopodobnie marnujesz dużą część czasu, wykonując te same zadania w kółko. Wprowadzasz pewne zmiany w kodzie, kompilujesz aplikację, uruchamiasz ją na urządzeniu lub emulatorze i bawisz się aplikacją, aby dowiedzieć się, czy działa zgodnie z oczekiwaniami.

Automatyzując testowanie interfejsu użytkownika, możesz automatycznie wykonywać te same czynności ręczne. Jeśli Twoja aplikacja ma przyzwoity rozmiar, może to zaoszczędzić dużo czasu, a także uchronić aplikację przed zawstydzającymi błędami, zwłaszcza tymi związanymi z regresją.

„Brzmi świetnie”, mówisz, ale jak to zrobić w aplikacji na Androida lub iOS?

Frameworki do testowania interfejsu użytkownika na Androida i iOS

Jeśli czytasz oficjalną dokumentację dla Androida i iOS, sugerują pisanie i uruchamianie testów interfejsu użytkownika w ich oficjalnych środowiskach IDE. Dla Androida to Android Studio, a dla iOS to Xcode.

Oficjalna dokumentacja posuwa się nawet do rekomendowania konkretnych frameworków do testowania. Oficjalna dokumentacja systemu Android obejmuje niektóre tematy dotyczące Espresso, platformy testowania interfejsu użytkownika systemu Android. Podobnie Apple sugeruje użycie frameworka XCTest.

A jeśli zamierzasz poważnie pracować nad testami interfejsu użytkownika, być może podążasz za tymi sugestiami, co ma sens, ponieważ Espresso jest utrzymywane przez Google i jest częścią repozytorium wsparcia Androida. Jest bardzo prawdopodobne, że Espresso będzie obsługiwać wszystkie nowe funkcje, które Google wprowadzi w przyszłości na Androida. To samo można powiedzieć o frameworku XCTest dla iOS.

Warto jednak pamiętać, że pomimo licznych korzyści płynących z automatycznego testowania, wielu programistów po prostu w ogóle ich nie pisze.

Każdy programista, który w głębi duszy ma świadomość automatyzacji testów, wie, że to świetny pomysł. Ale jeśli chodzi o siadanie i pisanie tych testów, wielu programistów zaczyna kwestionować, czy warto poświęcić im czas, ponieważ ręczne „dotknij przycisku” okazuje się znacznie szybszą operacją niż pisanie kodu, który „dotknie tego przycisku” automatycznie. Czasami klienci i menedżerowie, którzy niecierpliwie czekają na wypróbowanie aplikacji, również nie pomagają.

Wielu programistów w tym momencie decyduje, że lepiej kontynuować pracę nad nowymi funkcjami aplikacji, niż pisać automatyczne testy interfejsu użytkownika dla istniejących.

Gdy aplikacja się rozrasta, ręczne „dotykanie tych przycisków” za każdym razem, gdy aktualizujesz aplikację, staje się coraz bardziej czasochłonne.

Ale co by było, gdyby istniał framework, który ułatwiłby testowanie interfejsu użytkownika i nie dawał wymówki, aby nie pisać testów interfejsu użytkownika dla swoich aplikacji?

Poznaj Tykwa.

Tykwa: automatyczny test akceptacji dla aplikacji mobilnych

Około rok temu zacząłem szukać frameworka testowego, który będzie łatwy w użyciu dla osób, które nie są programistami. I wtedy znalazłem Calabash.

Ta platforma testowa typu open source, opracowana i utrzymywana przez zespół Xamarin, działa zarówno w systemie Android, jak i iOS. Umożliwia pisanie i wykonywanie automatycznych testów akceptacyjnych dla aplikacji mobilnych.

Testy akceptacyjne to zazwyczaj to, co następuje po testach systemu, które określają, czy Twoja aplikacja spełnia wymagania biznesowe. Biorąc pod uwagę, że działa na poziomie interfejsu użytkownika, działa to dobrze jako nasz wybór frameworku automatyzacji testowania interfejsu użytkownika.

Tykwa może wchodzić w interakcje z Twoją aplikacją, tak jak robi to Espresso lub XCTest. Jednak to, co sprawia, że ​​Calabash jest tutaj doskonałym wyborem, to wsparcie dla Ogórka.

Ogórek to narzędzie, które może uruchamiać automatyczne testy napisane w prostym języku angielskim (jeśli chcesz, możesz dostosować je do używania dowolnego innego prostego języka). Tak więc, aby pisać automatyczne testy na Cucumber, tester nie musi znać Java, Objective-C ani żadnego innego języka programowania.

Co sprawia, że ​​Tykwa działa?

Framework Calabash składa się z bibliotek, które mogą wchodzić w interakcje z aplikacjami na Androida i iOS. Można go uruchomić na prawdziwych urządzeniach. Dzięki temu może robić rzeczy, które tester robi ręcznie.

Na GitHubie dostępne są dwa różne projekty, dzięki którym Calabash jest możliwy:

• tykwa-android - dla Androida

• tykwa-ios - na iOS

Calabash może współpracować z dowolnym frameworkiem testowym opartym na Ruby. W tym artykule zajmiemy się Ogórkiem - najpopularniejszym i najwygodniejszym sposobem pisania testów na Calabash.

Zanim przejdziesz dalej, jeśli chcesz wypróbować Calabash zgodnie z resztą artykułu, upewnij się, że masz zainstalowany Ruby na swoim komputerze. Szczegółowe instrukcje instalacji znajdziesz tutaj.

Następnie zainstaluj Calabash na swojej ulubionej platformie, korzystając z powyższych linków GitHub.

Pisanie pierwszego testu na kalebasie

Pisanie testów na Calabash jest dość łatwe. Zobaczmy, jak wygląda prosty test aplikacji na iOS:

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

Tutaj aplikacja jest testowana z nieprawidłową nazwą użytkownika i hasłem, a następnie jest testowana z poprawną nazwą użytkownika i hasłem. Test oczekuje, że logowanie aplikacji nie powiedzie się w pierwszym scenariuszu, ale zakończy się sukcesem w drugim.

Możesz stworzyć tyle scenariuszy, ile potrzebujesz, a wszystko, co musisz zrobić, to podzielić kroki/instrukcje na proste angielskie zdania. Tak jak piszesz historię!

Każdy, kto wie o rozwoju opartym na zachowaniu (BDD), już się z tym zapozna.

Jak działa tykwa?

Aby zobaczyć, co dzieje się za krokami używanymi przez testera, możesz otworzyć projekt na GitHub i sprawdzić następujący plik:

 calabash-cucumber/features/step_definitions/calabash_steps.rb

Zobaczmy definicję następującego kroku:

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

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

Ten mały fragment kodu Rubiego szuka określonego pola, dotyka go, czeka na pojawienie się klawiatury, wpisuje tekst ze zmiennej text_to_type i czeka chwilę przed przejściem do następnego kroku.

Pierwszym słowem kroku może być „Dane”, „Kiedy”, „Wtedy”, „I” lub „Ale”. Nie ma znaczenia, jakiego słowa kluczowego użyjesz. Możesz użyć dowolnego z nich, aby historia była bardziej przejrzysta.

Jak dodać niestandardowe kroki

Jeśli potrzebujesz kroku, który nie jest jeszcze zaimplementowany w Calabash, możesz napisać go samodzielnie. Składnia jest dokładnie taka sama, jak w już zdefiniowanych krokach.

Na przykład, jeśli tester musi uzyskać dostęp do pola wejściowego za pomocą symbolu zastępczego, a nie nazwy pola:

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

Ta definicja kroku jest bardzo podobna do poprzedniej, ale uzyskujesz dostęp do pola za pomocą symbolu zastępczego zamiast nazwy pola. Biorąc pod uwagę wygląd Twojej aplikacji, może to jeszcze bardziej ułatwić testerowi.

Jest to również łatwe dla programisty. Deweloper implementuje krok raz, a następnie tester używa go, kiedy tylko tego potrzebuje. Co więcej, nie musisz dużo znać Rubiego, aby zaimplementować własne niestandardowe kroki.

Możesz znaleźć funkcje Ruby, których możesz użyć, tutaj:

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

Chmura testowa Xamarin

Podczas testowania aplikacji mobilnych jest jeszcze jedno wyzwanie. Powinieneś je przetestować na jak największej liczbie urządzeń, ponieważ jest tak wiele urządzeń i tak wiele wersji systemu operacyjnego.

W tym bardzo pomaga Xamarin Test Cloud. W chmurze jest około 2000 prawdziwych urządzeń i dobrą wiadomością jest to, że obsługuje testy Calabash.

Te same testy Calabash, które pomogły Ci zaoszczędzić czas, oszczędzając Ci wykonywania powtarzalnej pracy, mogą być teraz używane do testowania Twojej aplikacji na wielu rzeczywistych urządzeniach.

Zacznij pisać testy interfejsu użytkownika

Niezależnie od tego, czy Calabash jest rozwiązaniem testowym, którego potrzebuje Twoja aplikacja, z korzyściami, jakie przynosi, nie pozostawia miejsca na wymówki, jeśli chodzi o pisanie automatycznych testów interfejsu użytkownika dla aplikacji mobilnych. Tykwa może nie działać, jeśli Twoja aplikacja w dużym stopniu opiera się na niektórych funkcjach urządzenia (np. Aparat), ale nadal ułatwia pisanie testów dla większości aplikacji.