Test
Skoro wiemy już jak uruchomić serwer Appium i Emulator, możemy napisać pierwszy test. Będzie on sprawdzał poprawność funkcjonalności dodawania w Androidowym kalkulatorze.
Kod naszego testu wygląda następująco:
import unittest from appium import webdriver class CalculatorTest(unittest.TestCase): def setUp(self): desired_caps = {'platformName': 'Android', 'deviceName': 'p2api25', 'automationName': 'UiAutomator2', 'appPackage': 'com.android.calculator2', 'appActivity': 'com.android.calculator2.Calculator' } self.driver = webdriver.Remote('http://localhost:4723/wd/hub', desired_caps) def tearDown(self): self.driver.quit() def test_addition(self): expected_result = "4" key_two = self.driver.find_element_by_id('com.android.calculator2:id/digit_2') key_two.click() key_plus = self.driver.find_element_by_id('com.android.calculator2:id/op_add') key_plus.click() self.driver.find_element_by_id('com.android.calculator2:id/digit_2').click() self.driver.find_element_by_accessibility_id('equals').click() result = self.driver.find_element_by_id('com.android.calculator2:id/result').text self.assertEqual(expected_result, result) if __name__ == '__main__': unittest.main()
Składniki
Co robią wszystkie elementy tego kodu:
- metoda
setUp()
przygotowuje każdy test (definiuje, co powinno zostać wykonane, przed wykonaniem każdego testu). Więcej o test fixture można przeczytać tu: klik.
Co jest bardzo ważne: Jeżeli w metodzie setUp() pojawią się błędy – zostanie przerwane wykonywanie testu i nie zostanie wywołana metoda tearDown(). Należy zatem pamiętać o tym, aby nie umieszczać w niej żadnego niestabilnego kodu, w szczególności – żadnego związanego bezpośrednio z testami. Oczywiście, nasze testy są niezawodne 😉 , ale można sobie wyobrazić sytuację, w której – z jakiegokolwiek powodu – pojawia się błąd w emulatorze i nasza aplikacja się nie wyświetla: jeżeli umieścimy jakiekolwiek interakcje z aplikacją wewnątrz metody setUp(), pozostaniemy z otwartymi driverami (gdyż nie wywoła się metoda tearDown()) - metoda
tearDown()
zamyka każdy test: w niej zawieramy wszystkie polecenia, które mają być wykonane po zakończeniu każdego testu - metoda
test_addition()
: właściwa metoda testowa, zawiera zdefiniowany oczekiwany rezultat, kroki oraz asercję.
Co zrobiliśmy wewnątrz tych metod:
setUp()
:
zdefiniowaliśmy desired capabilities (podobnie jak w poprzednim wpisie o desktopowej wersji Appium), w których określiliśmy parametry naszej sesji (w tym informacje o aplikacji, która ma zostać uruchomiona – w przeciwieństwie do przykładu z poprzedniego wpisu, nie podaliśmy ścieżki do pliku *.apk, tylko nazwę już zainstalowanego pakietu).;
wywołaliśmy WebDriver Appium (metoda webdriver.Remote(), podając jego adres i desired capabilities).tearDown()
:
wywołujemy metodę kończącą działanie WebDriver’atest_addition
:
expected_result
– określa oczekiwany rezultat testu;
key_two = self.driver.find_element_by_id('com.android.calculator2:id/digit_2')
– znajduje klawisz „2” według jego id;
key_two.click()
– wywołuje kliknięcie na elemencie znalezionym w poprzednim kroku;
self.driver.find_element_by_id('com.android.calculator2:id/digit_2').click()
– robi dokładnie to samo co poprzednie dwa kroki z tą tylko różnicą, że nie tworzymy jawnie zmiennej przypisanej do znalezionego elementu;
self.driver.find_element_by_accessibility_id('equals').click()
– znajduje klawisz „=” i klika na niego, z tą tylko różnicą, że tym razem nie korzystamy z lokatora „Id”, a z „AccesibilityId”;
result = self.driver.find_element_by_id('com.android.calculator2:id/result').text
– znajduje element i pobiera jego tekst
self.assertEqual(expected_result, result)
– porównuje otrzymany rezultat z oczekiwanym, jeżeli są równe, test jest zakończony sukcesem
Uruchamianie
Przed odpaleniem testów powinniśmy mieć:
- uruchomiony emulator (z nazwą urządzenia taką jaką podamy w desired capabilities – w naszym przypadku „p2api25”)
- uruchomiony serwer Appium, pod adresem, który podajemy wywołując metodę webdriver.Remote()
Test możemy odpalić z poziomu konsoli wpisując python -m unittest {nazwa pliku}.py
lub korzystając z preferowanego test runnera.
Na zakończenie
Prezentowany fragment kodu nie powinien być traktowany jako wzorcowy: znajduje się w nich wiele elementów, które powodują, że przy większej ilości przypadków testowych kod będzie zawierał mnóstwo zwielokrotnionych fragmentów, jest on również bardzo nieczytelny. Należy go traktować wyłącznie jako najprostszy przykład uruchamiania testu przy użyciu Appium i Emulatora Androida.
W następnych wpisach skupię się na zaprezentowaniu kilku dobrych i nie-najgorszych praktyk, z których warto korzystać, jeżeli chcemy ułatwić sobie pisanie testów.