Złożona konfiguracja testowa

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

  • zainstaluj inne apki (oprócz testowego apk)
  • przesłać niektóre pliki do urządzenia
  • uruchamiaj polecenia (np. adb shell pm ...)

W przeszłości zespoły komponentów zwykle uciekały się do pisania testów po stronie hosta w celu wykonania takich zadań, co wymagało zrozumienia uprzęży Federacji Handlowej i zazwyczaj zwiększało złożoność modułu testowego.

Zapożyczając się z CTS, wprowadziliśmy koncepcję konfiguracji modułu testowego do obsługi takich zadań, powyższa lista wspólnych zadań może zostać osiągnięta za pomocą zaledwie kilku linii konfiguracji. Dla maksymalnej elastyczności, można nawet zaimplementować własną docelową przygotowujący, zdefiniowane przez ITargetPreparer lub ITargetCleaner i skonfigurować je do wykorzystania w swoim własnym modułem Test config.

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 uprząż automatyzacji testów Federacji Handlowej. Obecnie głównymi tagami obsługiwanymi przez konfiguracje modułu testowego są tagi „target_preparer” i „test”.

Przygotowujący docelowi

A „target_preparer” tag, jak sama nazwa wskazuje, określa przygotowujący docelowej (patrz ITargetPreparer ), który oferuje metody instalacji, która jest wywoływana przed moduł Test jest wykonywany do testowania; i jeśli klasa odwołuje się w „target_preparer” tag implementuje również ITargetCleaner , jego metoda porzuca zostanie wywołany po moduł testowy zakończył.

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ą zawartoś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:

  1. przed wywołaniem modułu testowego wykonaj polecenie powłoki „settings put secure access_enabled 1” na urządzeniu
  2. po zakończeniu testowania modułu wykonaj polecenie powłoki „settings put secure access_enabled 0”

W tym konkretnym przykładzie dostępność jest włączana/wyłączana odpowiednio przed/po wykonaniu modułu testowego. Przedstawiając prosty przykład, należy omówić więcej szczegółów na temat używania tagu „opcja”. Jak pokazano powyżej, tag może mieć dwa atrybuty: nazwa, wartość. Atrybut name wskazywał nazwę opcji i jest dalej podzielony na dwie części oddzielone dwukropkiem: skróconą nazwę osoby przygotowującej i rzeczywistą nazwę opcji oferowanej przez osobę przygotowującą.

Dokładne przeznaczenie pola wartości zależy od tego, jak przygotowujący zdefiniował opcję: może to być ciąg znaków, liczba, wartość logiczna, a nawet ścieżka do pliku itp. W powyższym przykładzie nazwa „run-command:run-command” oznacza że ustawiamy wartość dla opcji „run-command” zdefiniowanej przez docelowego przygotowującego o krótkiej nazwie „run-command”; a nazwa „run-command:teardown-command” oznacza, że ​​ustawiamy wartość dla opcji „teardown-command” również zdefiniowanej przez ten sam przygotowujący docelowy o krótkiej nazwie „run-command”. Oto podsumowanie trzech wspólnych osób przygotowujących cele:

  • Nazwa klasy: PushFilePreparer

    • Nazwa skrócona: push-file
    • Funkcja: popycha dowolnych plików w folderze testowym w przypadku przeznaczenia na urządzeniu
    • Uwagi:
      • ten przygotowujący może przesyłać z folderu do folderu lub z pliku do pliku; oznacza to, że nie możesz umieścić pliku w folderze na urządzeniu: musisz również określić docelową nazwę pliku w tym folderze
    • opcje:
      • Push: a push-Spec, sformatowany jako ' /path/to/srcfile.txt->/path/to/destfile.txt ' lub ' /path/to/srcfile.txt->/path/to/destdir/ '. Może się powtarzać Ta ścieżka może odnosić się do katalogu modułu testowego lub samego katalogu out.
      • ** post-Push: komenda ** A do uruchomienia na urządzeniu (z ` adb shell <your command> `) Wszakże popycha zostały próby. Typowym przypadkiem użycia byłoby użycie chmod dla uprawnień
  • Nazwa klasy: InstallApkSetup

    • Nazwa skrócona: install-apk
    • Funkcja: popycha dowolnych plików APK mocy do przeznaczenia na urządzeniu
    • opcje:
      • test-file-name: nazwa apk być zainstalowany na urządzeniu.
      • install-arg: Dodatkowe argumenty mają być przekazywane do godz polecenie zainstalowania, w tym wiodących myślnikiem, np „-d” może być powtórzony.
  • Nazwa klasy: RunCommandTargetPreparer

    • Skrócona nazwa: run-komenda
    • funkcyjne: Wykonuje dowolnych poleceń powłoki przed lub po wykonaniu moduł testujący
    • opcje:
      • run-polecenia: polecenie adb shell do uruchomienia. Może się powtórzyć
      • TEARDOWN podsystemu: polecenie ADB powłoki bieg w teardown fazie. Może się powtórzyć

Klasa testowa

Klasa testowa to klasa Federacji Handlowej używana 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: numeru GTEST

    • Nazwa skrócona: numeru GTEST
    • Funkcja: test, który działa natywny pakiet testowy na danym urządzeniu.
    • opcje:
      • rodzimy-test-device-path: Ścieżka na urządzeniu, gdzie znajdują się testy natywne.
  • Nazwa klasy: InstrumentationTest

    • Nazwa skrócona: oprzyrządowanie
    • Funkcja: test, który uruchamia pakiet testowy oprzyrządowania na danym urządzeniu
    • opcje:
      • Pakiet: Manifest nazwę pakietu Android aplikacji testowej do uruchomienia.
      • klasa: Nazwa klasy testu do uruchomienia.
      • Metoda: Nazwa metody testu uruchomić.
  • Nazwa klasy: AndroidJUnitTest

    • Funkcja: test, który uruchamia pakiet testowy oprzyrządowania na danym urządzeniu, używając android.support.test.runner.AndroidJUnitRunner Jest to główny sposób, aby wykonać test instrumentacji.