Niektóre moduły testowe mogą wymagać niestandardowych czynności konfiguracyjnych i demontażu, których nie można wykonać w ramach samego przypadku testowego. Typowe przykłady:
- instalować inne pliki APK (oprócz pliku testowego);
- Przekazywanie plików na urządzenie
- uruchamiać polecenia (np. adb shell pm...);
W przeszłości zespoły komponentów zwykle tworzyły testy po stronie hosta, aby wykonywać takie zadania. Wymagało to znajomości mechanizmu Trade Federation i zwykle zwiększało złożoność modułu testowego.
W ramach CTS wprowadziliśmy koncepcję konfiguracji modułu testowego, aby ułatwić wykonywanie takich zadań. Dzięki temu można wykonać wymienione powyżej typowe zadania za pomocą kilku linii konfiguracji. Aby zapewnić sobie maksymalną elastyczność, możesz nawet zaimplementować własne narzędzie do przygotowywania docelów zgodnie z definicją interfejsu ITargetPreparer lub ITargetCleaner i skonfigurować je do użycia w konfiguracji własnego modułu testowego.
Konfiguracja modułu testowania dla modułu testów to wymagany plik XML dodany do folderu źródłowego modułu najwyższego poziomu o nazwie „AndroidTest.xml”. Plik XML ma format pliku konfiguracji używanego przez jarzmo automatyzacji testów federacji handlowej. Obecnie główne tagi obsługiwane w konfiguracjach modułu testowego to tagi „target_preparer” i „test”.
Docelowi autorzy
Tag „target_preparer”, jak wskazuje nazwa, definiuje narzędzie do przygotowywania celów (patrz ITargetPreparer), które udostępnia metodę konfiguracji, która jest wywoływana przed wykonaniem modułu testowego w celu testowania. Jeśli klasa, do której odwołuje się tag „target_preparer”, implementuje również metodę ITargetCleaner, jej metoda dezaktywacji zostanie wywołana po zakończeniu modułu testowego.
Aby użyć wbudowanej wspólnej konfiguracji modułu, dodaj nowy plik „AndroidTest.xml” w folderze najwyższego poziomu modułu testowego i uzupełnij go o takie treści:
<?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 komentarzu „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 spowodują skonfigurowanie jarzma testowego, aby:
- zanim wywołany zostanie moduł testowy, na urządzeniu wykonaj polecenie „settings put secure accessibility_enabled 1” w powłoce
- Po zakończeniu modułu testowego wykonaj w powłoce polecenie „settings put secure accessibility_enabled 0”.
W tym przykładzie ułatwienia dostępu są włączane i wyłączane odpowiednio przed wykonaniem modułu testowego lub po nim. Aby zilustrować to za pomocą prostego przykładu, omówimy szczegółowo sposób korzystania z tagu „option”. Jak widać powyżej, tag może mieć 2 atrybuty: nazwę i wartość. Atrybut name musi odnosić się do jednej z opcji oferowanych przez osobę przygotowującą.
Dokładny cel pola wartości zależy od tego, jak zdefiniowano tę opcję: może to być ciąg znaków, liczba, wartość logiczna lub nawet ścieżka do pliku. Oto podsumowanie 3 najczęstszych typów przygotowujących:
Nazwa klasy: PushFilePreparer
- krótka nazwa: push-file
- function: przesyła dowolne pliki z folderu test case do miejsca docelowego na urządzeniu.
- Uwagi:
- ten przygotowujący może przesyłać dane z folderu do folderu lub z pliku do pliku, to znaczy, że nie można przesłać pliku do folderu na urządzeniu: należy również podać nazwę pliku docelowego w tym folderze
- opcje:
- push-file:specyfikacja push określająca plik lokalny do ścieżki, do której powinien zostać przesłany na urządzenie. Można się powtarzać. Jeśli skonfigurowano przesyłanie wielu plików do tej samej ścieżki zdalnej, zostanie przesłany najnowszy z nich.
- push: (wycofane) 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ć ścieżką względną do katalogu modułu testowego lub samego katalogu wyjściowego. - post-push: polecenie do uruchomienia na urządzeniu (z „
adb shell <your command>”) po wykonaniu wszystkich prób wypchnięcia. Typowym przypadkiem użycia jest użycie polecenia chmod w celu nadania 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 chcesz zainstalować na urządzeniu.
- install-arg: dodatkowe argumenty przekazywane do polecenia pm install, w tym myślnik na początku, np. „-d”. Może być powtarzany
nazwa klasy: RunCommandTargetPreparer,
- short name: run-command
- function: wykonuje dowolne polecenia powłoki przed lub po wykonaniu testu module.
- opcje:
- run-command: polecenie do wykonania w powłoce ADB. Może być powtarzany
- teardown-command: polecenie powłoki adb do wykonania na etapie demontażu. Może być powtarzany
Zajęcia testowe
Klasa testu to klasa Federacji Handlu, której używa się do wykonania 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 najczęstsze klasy testów:
nazwa klasy: GTest
- krótka nazwa: gtest
- function: test, który uruchamia natywny pakiet testów na danym urządzeniu.
- options:
- native-test-device-path: ścieżka na urządzeniu, na której znajdują się testy natywne.
Nazwa klasy: InstrumentationTest
- short name: instrumentation
- function: test, który uruchamia pakiet testów z instrumentacją na danym urządzeniu
- options:
- package: nazwa pakietu pliku manifestu aplikacji testowej na Androida, która ma zostać uruchomiona.
- class: nazwa klasy testu do uruchomienia.
- method: nazwa metody testowej 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 testów z instrumentacją.