Testuj mapowanie

Jest to krótkie wprowadzenie do mapowania testów i wyjaśnienie, jak łatwo rozpocząć konfigurowanie testów w projekcie Android Open Source Project (AOSP).

Co to jest mapowanie testowe?

Test Mapping to podejście oparte na Gerrit, które pozwala programistom tworzyć reguły testów przed i po przesłaniu bezpośrednio w drzewie źródłowym Androida i pozostawiać decyzje dotyczące gałęzi i urządzeń do przetestowania samej infrastrukturze testowej. Definicje mapowania testowego to pliki JSON o nazwie TEST_MAPPING, które można umieścić w dowolnym katalogu źródłowym.

Atest może używać plików TEST_MAPPING do uruchamiania testów przed przesłaniem w powiązanych katalogach. Dzięki mapowaniu testów możesz dodać ten sam zestaw testów, aby wstępnie przesłać sprawdzenia, wprowadzając prostą zmianę w drzewie źródłowym systemu Android.

Zobacz te przykłady:

Dodaj wstępne testy do TEST_MAPPING dla services.core

Dodaj testy wstępne do TEST_MAPPING dla narzędzi/zręczności za pomocą importów

Mapowanie testów opiera się na wiązce testowej Federacji Handlowej (TF) do wykonywania testów i raportowania wyników.

Definiowanie grup testowych

Test Mapping grupuje testy za pomocą grupy testowej . Nazwa grupy testowej może być dowolnym ciągiem. Na przykład wstępne przesłanie może dotyczyć grupy testów do uruchomienia podczas sprawdzania poprawności zmian. Testy po przesłaniu mogą być używane do sprawdzania poprawności kompilacji po scaleniu zmian.

Zasady tworzenia skryptów tworzenia pakietów

Aby wiązka testowa Federacji Handlowej mogła uruchamiać moduły testowe mapowania testów dla danej kompilacji, te moduły muszą mieć ustawioną opcję test_suite dla Soong lub LOCAL_COMPATIBILITY_SUITE dla Make dla jednego z tych dwóch pakietów:

  • ogólne-testy — testy, które nie zależą od funkcji specyficznych dla urządzenia (takich jak sprzęt specyficzny dla dostawcy, którego większość urządzeń nie posiada). Większość testów powinna znajdować się w zestawie testów ogólnych, nawet jeśli są one specyficzne dla jednego ABI lub funkcji bitowych lub sprzętowych, takich jak HWASan (istnieje osobny cel test_suites dla każdego ABI), a nawet jeśli muszą działać na urządzeniu.
  • urządzenia-testy - testy, które zależą od funkcjonalności urządzenia. Zazwyczaj testy te można znaleźć w sekcji vendor/ . Ponieważ „specyficzne dla urządzenia” nie odnosi się do funkcjonalności ABI lub SoC, które inne urządzenia mogą mieć lub nie, ale tylko do funkcjonalności, która jest unikalna dla danego urządzenia, dotyczy to testów JUnit tak samo jak natywnych testów GTest (co zwykle powinno być general-tests nawet jeśli są one specyficzne dla ABI).

Przykłady:

Android.bp: test_suites: ["general-tests"],
Android.mk: LOCAL_COMPATIBILITY_SUITE := general-tests

Konfigurowanie testów do uruchomienia w zestawie testów

Aby test mógł zostać uruchomiony w zestawie testów, test:

  • nie może mieć żadnego dostawcy kompilacji.
  • musi posprzątać po zakończeniu, na przykład usuwając wszelkie pliki tymczasowe wygenerowane podczas testu.
  • zmienić ustawienia systemu na wartość domyślną lub oryginalną.
  • nie powinien zakładać, że urządzenie jest w określonym stanie, np. gotowe do roota. Większość testów nie wymaga uprawnień administratora do uruchomienia. Jeśli test musi wymagać rootowania, powinien to określić za pomocą RootTargetPreparer w swoim AndroidTest.xml , jak w poniższym przykładzie:
<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>

Tworzenie plików mapowania testowego

W przypadku katalogu wymagającego pokrycia testowego wystarczy dodać plik JSON TEST_MAPPING podobny do poniższego przykładu. Reguły te zapewnią, że testy zostaną uruchomione w ramach kontroli przed przesłaniem, gdy zostaną dotknięte jakiekolwiek pliki w tym katalogu lub dowolnym z jego podkatalogów.

Idąc za przykładem

Oto przykładowy plik TEST_MAPPING (jest w formacie JSON, ale z obsługiwanymi komentarzami):

{
  "presubmit": [
    // JUnit test with options and file patterns.
    {
      "name": "CtsWindowManagerDeviceTestCases",
      "options": [
        {
          "include-annotation": "android.platform.test.annotations.RequiresDevice"
        }
      ],
      "file_patterns": ["(/|^)Window[^/]*\\.java", "(/|^)Activity[^/]*\\.java"]
    },
    // Device-side GTest with options.
    {
      "name" : "hello_world_test",
      "options": [
        {
          "native-test-flag": "\"servicename1 servicename2\""
        },
        {
          "native-test-timeout": "6000"
        }
      ]
    }
    // Host-side GTest.
    {
      "name" : "net_test_avrcp",
      "host" : true
    }
  ],
  "postsubmit": [
    {
      "name": "CtsWindowManagerDeviceTestCases"
    }
  ],
  "imports": [
    {
      "path": "frameworks/base/services/core/java/com/android/server/am"
    }
  ]
}

Ustawianie atrybutów

W powyższym przykładzie presubmit i postsubmit to nazwy każdej grupy testowej . Zobacz Definiowanie grup testowych, aby uzyskać więcej informacji o grupach testowych.

W wartości atrybutu name można ustawić nazwę modułu testowego lub nazwę testu integracyjnego Federacji Handlowej (ścieżka zasobu do testowego pliku XML, np. uiautomator/uiautomator-demo ). Zauważ, że pole name nie może zawierać name klasy ani name metody testowej. Aby zawęzić testy do uruchomienia, możesz użyć tutaj opcji, takich jak include-filter włączeń. Zobacz ( przykładowe użycie filtra uwzględniania ).

Ustawienie hosta testu wskazuje, czy test jest testem bez urządzenia uruchomionym na hoście, czy nie. Wartość domyślna to false , co oznacza, że ​​test wymaga uruchomienia urządzenia. Obsługiwane typy testów to HostGTest dla plików binarnych GTest i HostTest dla testów JUnit.

Atrybut file_patterns umożliwia ustawienie listy ciągów wyrażeń regularnych do dopasowania względnej ścieżki dowolnego pliku kodu źródłowego (względem katalogu zawierającego plik TEST_MAPPING). W powyższym przykładzie test CtsWindowManagerDeviceTestCases zostanie uruchomiony w trybie presubmit tylko wtedy, gdy dowolny plik java rozpoczyna się od okna lub działania, które znajdują się w tym samym katalogu co plik TEST_MAPPING lub którykolwiek z jego podkatalogów, zostanie zmieniony. Ukośniki odwrotne \ muszą zostać zmienione, ponieważ znajdują się w pliku JSON.

Atrybut importy umożliwia uwzględnienie testów w innych plikach TEST_MAPPING bez kopiowania zawartości. Zwróć uwagę, że pliki TEST_MAPPING w katalogach nadrzędnych importowanej ścieżki również zostaną uwzględnione. Mapowanie testowe umożliwia importowanie zagnieżdżone; oznacza to, że dwa pliki TEST_MAPPING mogą się wzajemnie importować, a Mapowanie testów jest w stanie prawidłowo scalić dołączone testy.

Atrybut options zawiera dodatkowe opcje wiersza poleceń TradeFed.

Aby uzyskać pełną listę dostępnych opcji dla danego testu, uruchom:

tradefed.sh run commandAndExit [test_module] --help

Zapoznaj się z sekcją Obsługa opcji TradeFed , aby uzyskać więcej informacji na temat działania opcji.

Uruchamianie testów z Atest

Aby wykonać lokalne reguły testu wstępnego przesłania:

  1. Przejdź do katalogu zawierającego plik TEST_MAPPING.
  2. Uruchom polecenie:
atest

Uruchamiane są wszystkie testy przed wysłaniem skonfigurowane w plikach TEST_MAPPING bieżącego katalogu i jego katalogów nadrzędnych. Atest zlokalizuje i przeprowadzi dwa testy dla przedłożenia (A i B).

Jest to najprostszy sposób uruchamiania testów przed przesłaniem w plikach TEST_MAPPING w bieżącym katalogu roboczym (CWD) i katalogach nadrzędnych. Atest zlokalizuje i użyje pliku TEST_MAPPING w CWD i wszystkich jego katalogach nadrzędnych.

Strukturyzacja kodu źródłowego

Poniższy przykład pokazuje, jak można skonfigurować pliki TEST_MAPPING w drzewie źródłowym.

src
├── project_1
│   └── TEST_MAPPING
├── project_2
│   └── TEST_MAPPING
└── TEST_MAPPING

Zawartość src/TEST_MAPPING :

{
  "presubmit": [
    {
      "name": "A"
    }
  ]
}

Zawartość src/project_1/TEST_MAPPING :

{
  "presubmit": [
    {
      "name": "B"
    }
  ],
  "postsubmit": [
    {
      "name": "C"
    }
  ],
  "other_group": [
    {
      "name": "X"
    }
  ]}

Zawartość src/project_2/TEST_MAPPING :

{
  "presubmit": [
    {
      "name": "D"
    }
  ],
  "import": [
    {
      "path": "src/project_1"
    }
  ]}

Określanie katalogów docelowych

Możesz określić katalog docelowy do uruchamiania testów w plikach TEST_MAPPING w tym katalogu. Następujące polecenie uruchomi dwa testy (A, B).

atest --test-mapping src/project_1

Uruchamianie reguł testu po przesłaniu

Możesz również użyć tego polecenia, aby uruchomić reguły testu postsubmit zdefiniowane w TEST_MAPPING w src_path (domyślnie CWD) i jego katalogach nadrzędnych:

atest [--test-mapping] [src_path]:postsubmit

Uruchamianie tylko testów, które nie wymagają żadnego urządzenia

Możesz użyć opcji --host dla Atest, aby uruchomić tylko testy skonfigurowane na hoście, które nie wymagają żadnego urządzenia. Bez tej opcji Atest uruchomi oba testy, te wymagające urządzenia i te działające na hoście i nie wymagają żadnego urządzenia. Testy będą prowadzone w dwóch oddzielnych pakietach.

atest [--test-mapping] --host

Identyfikacja grup testowych

Grupy testowe można określić w poleceniu Atest. Następujące polecenie uruchomi wszystkie testy postsubmit związane z plikami w katalogu src/project_1, który zawiera tylko jeden test (C).

Możesz też użyć :all do uruchomienia wszystkich testów niezależnie od grupy. Następujące polecenie uruchamia cztery testy (A, B, C, X):

atest --test-mapping src/project_1:all

W tym podkatalogi

Domyślnie uruchamianie testów w TEST_MAPPING za pomocą Atest spowoduje uruchomienie tylko testów wstępnie przesłanych skonfigurowanych w pliku TEST_MAPPING w CWD (lub podanym katalogu) i jego katalogach nadrzędnych. Jeśli chcesz uruchomić testy we wszystkich plikach TEST_MAPPING w podkatalogach, użyj opcji --include-subdir , aby zmusić Atest do uwzględnienia również tych testów.

atest --include-subdir

Bez opcji --include-subdir Atest uruchomi tylko test A. Z opcją --include-subdir Atest uruchomi dwa testy (A, B).

Obsługiwany jest komentarz na poziomie wiersza

Możesz dodać komentarz // -format na poziomie wiersza, aby uzupełnić plik TEST_MAPPING o opis ustawienia, które następuje. ATest and Trade Federation wstępnie przetworzy TEST_MAPPING do prawidłowego formatu JSON bez komentarzy. Aby plik JSON był czysty i łatwy do odczytania, obsługiwany jest tylko komentarz // -format na poziomie wiersza.

Przykład:

{
  // For presubmit test group.
  "presubmit": [
    {
      // Run test on module A.
      "name": "A"
    }
  ]
}