Jak uruchomić testy automatyczne na emulatorze Android w CI w 5 krokach?

Z tego artykułu dowiesz się, w jaki sposób uruchomić testy automatyczne napisane w Appium na emulatorze uruchomionym w kontenerze dockerowym. W tym przypadku są one napisane w języku Java, ale możesz zmienić na dowolny wspierany język, który wykorzystujesz. Tak przygotowaną konfigurację możesz wykorzystać do uruchamiania testów na maszynach zdalnych dla testów automatycznych w środowiskach CI np. Jenkins lub GitLab CI.

Konfiguracja środowiska

Co jest potrzebne do rozpoczęcia pracy:

1. Procesor, który obsługuje vmx/svm.

2. System operacyjny docelowo Linux, ale na Windowsie również możemy przeprowadzić testową konfigurację.

3. Docker.

Aby sprawdzić, czy twój procesor obsługuje svm/vmx skorzystaj z instrukcji podanej w linku.

Komenda:

‍

Jeżeli wartość zwrócona jest większa od 0, oznacza to, że ten procesor jest w stanie obsłużyć to rozwiązanie. Po weryfikacji należy kierować się dalszą częścią instrukcji z linku i zainstalować zależności dla KVM, w zależności od wersji systemu Linux, lub przejść do kroku 2 gdzie został przygotowany obraz dockerowy ze wszystkimi zależnościami.

W przypadku gdy chcesz przeprowadzić testy na maszynie z Windowsem polecam uruchomić kontener np. z Ubuntu, a w nim zainstalować wszelkie zależności zgodnie z instrukcją w linku z punktu pierwszego (lub skorzystać z dockerfile przygotowanego w kroku 2).

Rozwiązanie, które proponuję wykorzystuje DIND (Docker in Docker) jednak nie musimy korzystać z DIND możemy zainstalować wszelkie zależności bezpośrednio na maszynie docelowej.

Przygotowanie obrazu bazowego do uruchomienia DIND

Poniżej znajdziesz skrypt dockerfile, na podstawie którego możesz stworzyć swój obraz zawierający wszystkie zależności z powyższej konfiguracji. Jeżeli nie korzystasz z Javy oraz Mavena do uruchamiania swoich testów, możesz usunąć zależności openjdk-11-jdk Maven i podać biblioteki wykorzystywane przez twój projekt testowy.

Powyższy skrypt zapisz do pliku dockerfile, a następnie w konsoli w lokalizacji, w której znajduje się plik dockerfile wywołaj polecenie:

‍

Tak zbudujesz gotowy obraz, który będzie posiadał wszystkie zależności niezbędne do uruchomienia naszych testów. Obraz możesz następnie uruchomić jako kontener na swoim lokalnym komputerze lub bezpośrednio wykorzystać do konfiguracji na GitLab CI, o czym mowa w dalszej części artykułu.

* Jeżeli nie chcesz korzystać z podejścia DIND, zainstaluj wszystkie zależności za pomocą terminala na swojej maszynie docelowej.

** Jeżeli korzystasz z maszyny Windows, zbuduj powyższy obraz, następnie wejdź do wnętrza kontenera. Dzięki temu będziesz mieć możliwość korzystania z systemu linuksowego i jego poleceń, w CMD wprowadź komendę, gdzie image_id zastąpisz nazwą obrazu wybudowanego obrazu:

Uruchomienie kontenera z emulatorem

W celu uruchomienia emulatora należy użyć skryptu docker-compose.yaml

Skrypt stworzy dwa kontenery: Selenium Hub i Nexus Emulator. Usługi działają w swoim własnym kontenerze i są połączone w jedną sieć o nazwie "my_network" tak, aby kontenery widziały się wzajemnie (w volumes można ustawić ścieżki do swojego app.apk, ale nie jest to wymagane).

Powyższy skrypt docker-compose.yaml wywołujemy na maszynie docelowej za pomocą komendy:

‍

Po wpisaniu komendy:

‍

powinniśmy zobaczyć następujący wynik:

Należy skopiować aplikację do wnętrza kontenera docker-android (nexus_emulator) w następujący sposób:

‍

Gdzie 6d590cc0737f to id waszego kontenera.

Po wejściu na adres http://localhost:6080 lub http://172.16.0.1:6080 powinien być widoczny emulator oraz konsola:

Konfiguracja projektu testowego

Konfiguracja projektu powinna wyglądać następująco:

‍

Gdzie serverurl to adres gateway, w którym znajduje się emulatorem nexus, na którym uruchomiony jest Appium server, a apppath to ścieżka do aplikacji wewnątrz kontenera dockerowego. Jeżeli nie korzystasz z podejścia DIND, http://localhost:4723/wd/hub także będzie poprawnym adresem.

Server URL może także być ustawiony na http://localhost:4444/wd/hub, w ten sposób wykorzystamy kontener z Selenium Hub, przy tym podejściu wymagane jest podanie devicename do capabilities w naszych testach.

Konfiguracja GitLab CI runnera DIND

Jeżeli konfigurujemy całość pod DIND najważniejsze w konfiguracji GitLab runnera to privilege = true oraz podpięcie w woluminach docker.sock.

Podczas rejestracji nowej maszyny jako runner (https://docs.gitlab.com/runner/install/) możemy podać nazwę obrazu dockerowego (który stworzyliśmy na bazie dockerfile z kroku pierwszego), na jakim ma zostać uruchomiony job (nie ma konieczności robienia tego podczas konfiguracji, można to zrobić bezpośrednio w konfiguracji joba w skrypcie gitlabci.yaml).

Kilka wskazówek na koniec:

1. Wykorzystując podejście DIND należy pamiętać, że montowane ścieżki są ścieżkami hosta (dlatego w instrukcji podaję komendę docker cp).

2. Korzystając z podejścia DIND koniecznie zamontuj docker.sock.

3. Instalując wszystko na hoście nie korzystając z DIND nie ma potrzeby odwoływania się za pomocą gateway, możesz wykorzystać localhost.