Niektóre moduły testowe mogą wymagać niestandardowych kroków konfiguracji i zamykania, których nie można wykonać w ramach samego przypadku testowego. Typowe przykłady:
- instalować inne pliki APK (oprócz testowego pliku APK);
- przesyłać niektóre pliki na urządzenie,
- uruchamiać polecenia (np. adb shell pm ...),
W przeszłości zespoły zajmujące się komponentami zwykle pisały testy po stronie hosta, aby wykonywać takie zadania. Wymagało to zrozumienia platformy Trade Federation i zwykle zwiększało złożoność modułu testowego.
Wprowadziliśmy koncepcję konfiguracji modułu testowego, aby obsługiwać takie zadania. Listę typowych zadań powyżej można osiągnąć za pomocą zaledwie kilku wierszy konfiguracji. Aby uzyskać maksymalną elastyczność, możesz nawet wdrożyć własny preparator docelowy zdefiniowany przez interfejs ITargetPreparer lub ITargetCleaner i skonfigurować go do użycia we własnej konfiguracji modułu testowego.
Konfiguracja modułu testowego to wymagany plik XML dodany do folderu źródłowego modułu najwyższego poziomu o nazwie „AndroidTest.xml”. Plik XML ma format pliku konfiguracyjnego używanego przez jarzmo automatyzacji testów Trade Federation. Obecnie głównymi tagami obsługiwanymi przez konfiguracje modułu testowego są tagi „target_preparer” i „test”.
Docelowi przygotowujący
Tag „target_preparer”, jak sama nazwa wskazuje, definiuje przygotowującego urządzenie docelowe (patrz ITargetPreparer), który udostępnia metodę konfiguracji wywoływaną przed wykonaniem modułu testowego na potrzeby testowania. Jeśli klasa, do której odwołuje się tag „target_preparer”, implementuje też interfejs ITargetCleaner, po zakończeniu modułu testowego zostanie wywołana jej metoda zamykania.
Aby użyć wbudowanej konfiguracji modułu wspólnego, dodaj nowy plik „AndroidTest.xml” w folderze najwyższego poziomu modułu testowego i wypełnij go tymi treściami:
<?xml version="1.0" encoding="utf-8"?>
<!-- [insert standard AOSP copyright here] -->
<configuration description="Test module config for Foo">
<!-- insert options here -->
</configuration>
Możemy na przykład dodać te tagi opcji (w miejscu komentarza „insert” powyżej):
<target_preparer class="com.android.tradefed.targetprep.RunCommandTargetPreparer">
<option name="run-command" value="settings put secure accessibility_enabled 1" />
<option name="teardown-command" value="settings put secure accessibility_enabled 0" />
</target_preparer>
Te opcje skonfigurują środowisko testowe w taki sposób, aby:
- przed wywołaniem modułu testowego wykonaj na urządzeniu polecenie powłoki „settings put secure accessibility_enabled 1”
- po zakończeniu modułu testowego wykonaj polecenie powłoki „settings put secure accessibility_enabled 0”
W tym konkretnym przykładzie ułatwienia dostępu są włączane/wyłączane odpowiednio przed/po wykonaniu modułu testowego. Po zaprezentowaniu prostego przykładu musimy omówić więcej szczegółów dotyczących użycia tagu „option”. Jak widać powyżej, tag może mieć 2 atrybuty: name i value. Atrybut name musi odnosić się do jednej z opcji oferowanych przez osobę przygotowującą.
Dokładne przeznaczenie pola wartości zależy od tego, jak osoba przygotowująca zdefiniowała opcję: może to być ciąg znaków, liczba, wartość logiczna lub nawet ścieżka do pliku. Oto podsumowanie 3 najczęstszych preparatów docelowych:
nazwa klasy: PushFilePreparer
- short name: push-file
- function: przesyła dowolne pliki z folderu testowego do miejsca docelowego na urządzeniu.
- Uwagi:
- osoba przygotowująca może przenosić dane z folderu do folderu lub z pliku do pliku, co oznacza, że nie można przenieść pliku z folderu na urządzeniu: musisz też podać nazwę pliku docelowego w tym folderze.
- options:
- push-file: specyfikacja push, która określa lokalny plik do ścieżki, w której ma być umieszczony na urządzeniu. Można powtarzać. Jeśli wiele plików jest skonfigurowanych do przesłania do tej samej ścieżki zdalnej, zostanie przesłany najnowszy z nich.
- push: (przestarzałe) specyfikacja push w formacie „
/path/to/srcfile.txt->/path/to/destfile.txt” lub „/path/to/srcfile.txt->/path/to/destdir/”. Może się powtarzać. Ścieżka może być względna w stosunku do katalogu modułu testowego lub samego katalogu wyjściowego. - post-push: polecenie do uruchomienia na urządzeniu (z użyciem `
adb shell <your command>`) po podjęciu wszystkich prób wysłania powiadomień push. Typowym przypadkiem użycia jest użycie polecenia chmod do ustawiania uprawnień.
nazwa klasy: InstallApkSetup
- Krótka nazwa: install-apk
- function: przesyła dowolne pliki APK do miejsca docelowego na urządzeniu.
- options:
- test-file-name: nazwa pliku APK, który ma zostać zainstalowany na urządzeniu.
- install-arg: dodatkowe argumenty, które mają być przekazywane do polecenia pm install, w tym kreska na początku, np. „-d”. Można powtarzać
nazwa klasy: RunCommandTargetPreparer
- short name: run-command
- function: wykonuje dowolne polecenia powłoki przed lub po wykonaniu modułu testowego
- options:
- run-command: polecenie powłoki ADB do uruchomienia. Można powtarzać
- teardown-command: polecenie powłoki adb do uruchomienia w fazie zamykania. Można powtarzać
Klasa testowa
Klasa testowa to klasa Trade Federation, która będzie używana do przeprowadzania testu.
<test class="com.android.tradefed.testtype.AndroidJUnitTest">
<option name="package" value="android.test.example.helloworld"/>
<option name="runner" value="android.support.test.runner.AndroidJUnitRunner"/>
</test>
Oto 3 typy testów:
nazwa klasy: GTest
- krótka nazwa: gtest
- function: test, który uruchamia natywny pakiet testowy na danym urządzeniu.
- options:
- native-test-device-path: ścieżka na urządzeniu, w której znajdują się testy natywne.
nazwa klasy: InstrumentationTest
- Krótka nazwa: instrumentacja
- function: Test, który uruchamia pakiet testu z instrumentacją na danym urządzeniu.
- options:
- package: nazwa pakietu manifestu aplikacji testowej na Androida, która ma zostać uruchomiona.
- class: nazwa klasy testu do uruchomienia.
- method: nazwa metody testowania do uruchomienia.
nazwa klasy: AndroidJUnitTest
- function: Test, który uruchamia pakiet testów z instrumentacją na danym urządzeniu za pomocą klasy android.support.test.runner.AndroidJUnitRunner. Jest to główny sposób wykonywania testu z instrumentacją.