Niektóre moduły testowe mogą wymagać niestandardowej konfiguracji i demontażu, których nie można wykonać w ramach samego przypadku testowego. Typowe przykłady mogą obejmować:
- zainstaluj inne apki (oprócz apki testowej)
- przesłać niektóre pliki do urządzenia
- uruchom polecenia (np. adb shell pm ...)
W przeszłości zespoły komponentów zazwyczaj uciekały się do pisania testów po stronie hosta w celu wykonania takich zadań, co wymagało zrozumienia okablowania Federacji Handlowej i zazwyczaj zwiększało złożoność modułu testowego.
Pożyczając od CTS, wprowadziliśmy koncepcję konfiguracji modułu testowego do obsługi takich zadań, powyższą listę typowych zadań można osiągnąć za pomocą zaledwie kilku linii konfiguracji. Aby uzyskać maksymalną elastyczność, możesz nawet zaimplementować własny element przygotowujący elementy docelowe, zgodnie z definicją ITargetPreparer lub ITargetCleaner , i skonfigurować je do użycia we własnej konfiguracji modułu testowego.
Konfiguracja modułu testowego dla modułu testowego to wymagany plik XML dodany do folderu źródłowego modułu najwyższego poziomu o nazwie „AndroidTest.xml”. XML jest zgodny z formatem pliku konfiguracyjnego używanego przez wiązkę automatyzacji testów Federacji Handlowej. Obecnie głównymi tagami obsługiwanymi przez konfiguracje modułu testowego są tagi „target_preparer” i „test”.
Osoby przygotowujące cele
Znacznik „target_preparer”, jak sama nazwa wskazuje, definiuje docelowe narzędzie przygotowujące (patrz ITargetPreparer ), które oferuje metodę konfiguracji, która jest wywoływana przed wykonaniem modułu testowego w celu przetestowania; a jeśli klasa, do której odwołuje się znacznik „target_preparer”, implementuje również narzędzie ITargetCleaner , jego metoda rozerwania zostanie wywołana po zakończeniu modułu testowego.
Aby użyć wbudowanej konfiguracji wspólnego modułu, dodaj nowy plik „AndroidTest.xml” w folderze najwyższego poziomu modułu testowego i wypełnij go następującą 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>
Jako przykład możemy dodać następujące tagi opcji (w komentarzu „wstaw” 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>
Opcje skonfigurują wiązkę testową tak, aby:
- przed wywołaniem modułu testowego wykonaj polecenie powłoki „settings put secure accessibility_enabled 1” na urządzeniu
- po zakończeniu modułu testowego wykonaj polecenie powłoki „settings put secure accessibility_enabled 0”
W tym konkretnym przykładzie dostępność jest włączana/wyłączana odpowiednio przed/po wykonaniu modułu testowego. Mając zademonstrowany prosty przykład, konieczne jest omówienie bardziej szczegółowych informacji na temat używania znacznika „opcja”. Jak pokazano powyżej, tag może mieć dwa atrybuty: nazwa, wartość. Atrybut name musi odnosić się do jednej z opcji oferowanych przez sporządzającego.
Dokładny cel 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, a nawet ścieżka do pliku. Oto podsumowanie trzech typowych osób przygotowujących cele:
nazwa klasy: PushFilePreparer
- krótka nazwa : plik push
- funkcja : wypycha dowolne pliki z folderu przypadku testowego do miejsca docelowego na urządzeniu
- uwagi :
- ten przygotowujący może przekazywać z folderu do folderu lub z pliku do pliku; oznacza to, że nie można przesłać pliku do folderu na urządzeniu: należy również określić nazwę pliku docelowego w tym folderze
- opcje :
- push-file: Specyfikacja push, określająca plik lokalny w ścieżce, w której powinien zostać wypchnięty na urządzenie. Może się powtórzyć. Jeśli wiele plików jest skonfigurowanych do wypychania do tej samej zdalnej ścieżki, najnowszy plik zostanie wypchnięty.
- push: (przestarzałe) Specyfikacja push, sformatowana jako „
/path/to/srcfile.txt->/path/to/destfile.txt” lub „/path/to/srcfile.txt->/path/to/destdir/'. Może się powtórzyć. Ta ś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 `
adb shell <your command>`) po wszystkich próbach wypychania. Typowym przypadkiem użycia byłoby użycie chmod dla uprawnień
nazwa klasy: InstallApkSetup
- krótka nazwa: install-apk
- funkcja: wypycha dowolne pliki apk do miejsca docelowego na urządzeniu
- opcje:
- nazwa-pliku-testowego: nazwa aplikacji, która ma zostać zainstalowana na urządzeniu.
- install-arg: Dodatkowe argumenty do przekazania do komendy pm install, w tym wiodący myślnik, np. „-d”. Można powtórzyć
nazwa klasy: RunCommandTargetPreparer
- krótka nazwa: uruchom-polecenie
- funkcja: wykonuje dowolne polecenia powłoki przed lub po wykonaniu modułu testowego
- opcje:
- run-command: polecenie powłoki adb do uruchomienia. Może się powtórzyć
- polecenie rozdarcia: polecenie powłoki adb do uruchomienia podczas fazy rozdarcia. Może się powtórzyć
Klasa testowa
Klasa testowa to klasa Federacji Handlowej, której należy użyć 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 trzy popularne klasy testów:
nazwa klasy: GTest
- krótka nazwa: gtest
- funkcja: Test, który uruchamia natywny pakiet testowy na danym urządzeniu.
- opcje:
- native-test-device-path: Ścieżka na urządzeniu, na którym znajdują się testy natywne.
nazwa klasy: InstrumentationTest
- nazwa skrócona: oprzyrządowanie
- funkcja: test uruchamiający pakiet testów oprzyrządowania na danym urządzeniu
- opcje:
- package: Nazwa pakietu manifestu aplikacji testowej systemu Android do uruchomienia.
- class: Nazwa klasy testowej do uruchomienia.
- metoda: nazwa metody testowej do uruchomienia.
nazwa klasy: AndroidJUnitTest
- funkcja: Test, który uruchamia pakiet testów oprzyrządowania na danym urządzeniu za pomocą android.support.test.runner.AndroidJUnitRunner Jest to główny sposób wykonania testu oprzyrządowania.