Złożona konfiguracja testu

Niektóre moduły testowe mogą wymagać niestandardowej konfiguracji i demontażu, których nie można wykonać w samym przypadku testowym. Typowe przykłady mogą obejmować:

  • zainstaluj inne aplikacje (oprócz aplikacji testowej)
  • wypchnij niektóre pliki na urządzenie
  • uruchamiaj polecenia (np. adb Shell pm ...)

W przeszłości zespoły tworzące komponenty zazwyczaj uciekały się do pisania testów po stronie hosta, aby wykonać takie zadania, co wymagało zrozumienia uprzęży Federacji Handlowej i zazwyczaj zwiększało złożoność modułu testowego.

Zapoż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 program 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 moduł przygotowujący cel (patrz ITargetPreparer ), który oferuje metodę konfiguracji, która jest wywoływana przed wykonaniem modułu testowego w celu testowania; a jeśli klasa wymieniona w tagu „target_preparer” implementuje również ITargetCleaner , jej metoda rozbijania zostanie wywołana po zakończeniu modułu testowego.

Aby skorzystać z wbudowanej wspólnej konfiguracji 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 znaczniki 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ą w następujący sposób:

  1. przed wywołaniem modułu testowego wykonaj na urządzeniu polecenie powłoki „ustawienia umieścić bezpieczną dostępność_enabled 1”
  2. po zakończeniu modułu testowego wykonaj polecenie powłoki „ustawienia put secure accessibility_enabled 0”

W tym konkretnym przykładzie dostępność jest włączana/wyłączana odpowiednio przed/po wykonaniu modułu testowego. Na prostym przykładzie konieczne jest omówienie bardziej szczegółowych informacji na temat sposobu użycia znacznika „opcja”. Jak pokazano powyżej, tag może mieć dwa atrybuty: nazwę i wartość. Atrybut nazwa musi odnosić się do jednej z opcji oferowanych przez sporządzającego.

Dokładny cel pola wartości zależy od tego, jak przygotowujący zdefiniował opcję: może to być ciąg znaków, liczba, wartość logiczna lub nawet ścieżka do pliku. Oto podsumowanie trzech popularnych narzędzi do przygotowywania celów:

  • nazwa klasy: PushFilePreparer

    • krótka nazwa : plik push
    • funkcja : wypycha dowolne pliki z folderu przypadków testowych do miejsca docelowego na urządzeniu
    • notatki :
      • ten przygotowujący może przesyłać dane z folderu do folderu lub pliku do pliku; oznacza to, że nie można przekazać pliku do folderu na urządzeniu: należy również określić docelową nazwę pliku w tym folderze
    • opcje :
      • push-file: specyfikacja push, określająca plik lokalny do ścieżki, w której powinien zostać przekazany na urządzenie. Może zostać powtórzone. Jeśli skonfigurowano przesyłanie wielu plików do tej samej ścieżki zdalnej, wypchnięty zostanie najnowszy.
      • 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 zostać powtórzone. Ścieżka ta może odnosić się do katalogu modułu testowego lub samego katalogu out.
      • post-push: Polecenie do uruchomienia na urządzeniu (z ` adb shell <your command> `) po wykonaniu wszystkich prób wypchnięcia. Typowym przypadkiem użycia byłoby użycie chmod w celu uzyskania uprawnień
  • nazwa klasy: InstallApkSetup

    • krótka nazwa: install-apk
    • funkcja: przesyła 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, które należy przekazać do polecenia pm install, łącznie z myślnikiem wiodącym, np. „-d”. Można powtórzyć
  • nazwa klasy: RunCommandTargetPreparer

    • krótka nazwa: polecenie uruchomienia
    • funkcja: wykonuje dowolne polecenia powłoki przed lub po wykonaniu modułu testowego
    • opcje:
      • polecenie uruchomienia: polecenie powłoki adb do uruchomienia. Może zostać powtórzone
      • polecenie porzucenia: polecenie powłoki adb do uruchomienia w fazie porzucania. Może zostać powtórzone

Klasa testowa

Klasa testowa to klasa Federacji Handlowej, która ma zostać użyta 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 testowe:

  • nazwa klasy: GTest

    • krótka nazwa: gtest
    • funkcja: Test uruchamiający 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

    • krótka nazwa: oprzyrządowanie
    • funkcja: Test uruchamiający pakiet testów oprzyrządowania na danym urządzeniu
    • opcje:
      • pakiet: 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 uruchamiający pakiet testów oprzyrządowania na danym urządzeniu przy użyciu android.support.test.runner.AndroidJUnitRunner Jest to główny sposób wykonania testu oprzyrządowania.