Konfiguracja złożonego testu

Niektóre moduły testów 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),
  • przesyłać pliki 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 wyż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, zdefiniowane przez interfejs ITargetPreparer lub ITargetCleaner, i skonfigurować je do użycia w konfiguracji własnego modułu testowego.

Konfiguracja modułu testowego to wymagany plik XML dodany do najwyższego folderu źródłowego modułu o nazwie „AndroidTest.xml”. Plik XML jest zgodny z formatem pliku konfiguracyjnego używanego przez mechanizm automatyzacji testów Trade Federation. Obecnie główne tagi obsługiwane przez konfiguracje modułu testowego to tagi „target_preparer” i „test”.

Docelowi autorzy

Tag „target_preparer”, jak sugeruje nazwa, definiuje obiekt do przygotowywania docelowego (patrz ITargetPreparer), który udostępnia metodę konfiguracji wywoływaną przed wykonaniem modułu testowego. Jeśli klasa, do której odwołuje się tag „target_preparer”, implementuje też interfejs ITargetCleaner, to po zakończeniu modułu testowego zostanie wywołana jego metoda porządkowania.

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>

Opcje te skonfigurują zestaw testowy, aby:

  1. Zanim wywołasz moduł testowy, na urządzeniu wykonaj polecenie „settings put secure accessibility_enabled 1” w powłoce.
  2. 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/wyłączane odpowiednio przed i po wykonaniu modułu testu. 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 autora.

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, która określa ścieżkę do pliku lokalnego, gdzie powinien zostać przesłany na urządzenie. mogą być powtarzane; Jeśli skonfigurowano przesyłanie wielu plików do tej samej ścieżki zdalnej, zostanie przesłany najnowszy z nich.
      • push: (deprecated) specyfikacja push, sformatowana jako /path/to/srcfile.txt->/path/to/destfile.txt lub /path/to/srcfile.txt->/path/to/destdir/. Może być powtarzana. Ścieżka może być ścieżką względną do katalogu modułu testowego lub samego katalogu wyjściowego.
      • post-push: polecenie do wykonania na urządzeniu (z parametrem „adb shell <your command>”) po wykonaniu wszystkich poleceń push. 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:
      • nazwa-pliku-testowego:nazwa pliku APK, który ma zostać zainstalowany 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,

    • krótka nazwa: run-command
    • function: wykonuje dowolne polecenia powłoki przed lub po wykonaniu testu module.
    • options:
      • 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

Klasa testowa

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 określonym 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 testu do wykonania.

  • Nazwa klasy: AndroidJUnitTest

    • function: test, który uruchamia pakiet testów z instrumentacją na danym urządzeniu za pomocą pakietu android.support.test.runner.AndroidJUnitRunner. Jest to główny sposób wykonywania testów z instrumentacją.