Oto krótkie wprowadzenie do mapowania testów i wyjaśnienie, jak łatwo rozpocząć konfigurowanie testów w ramach projektu Android Open Source Project (AOSP).
Mapowanie testowe
Mapowanie testów 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, a decyzje dotyczące gałęzi i urządzeń pozostawiają 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ć testy, wykonując prostą zmianę w drzewie źródłowym Androida.
Zobacz te przykłady:
Dodaj testy przed przesłaniem do TEST_MAPPING for services.core
Dodaj testy przed przesłaniem do narzędzia TEST_MAPPING dotyczące narzędzi/deteksu za pomocą importu
Przeprowadzanie testów i raportowanie wyników korzysta z zapasu testowego federacji handlowej (TF).
Zdefiniuj grupy testowe
Testuj grupy mapowania za pomocą grupy testowej. Nazwa grupy testowej może być dowolnym ciągiem znaków. Na przykład wstępne przesyłanie może dotyczyć grupy testów, które mają być uruchomione podczas weryfikowania zmian. Za pomocą testów postsubmit można zweryfikować kompilacje po scaleniu zmian.
Reguły skryptu tworzenia pakietu
Aby zasilacz testów federacji handlowej mógł uruchamiać moduły testowe mapowania testów w przypadku danej kompilacji, moduły te muszą mieć ustawiony parametr test_suites dla Soong lub LOCAL_COMPATIBILITY_SUITE dla ustawienia Make w jednym z tych 2 zestawów:
- testy ogólne – testy, które nie opierają się na funkcjach urządzenia (np. testy dotyczące konkretnego dostawcy sprzętu, którego większość urządzeń nie ma). Większość testów powinna należeć do zestawu testów ogólnych, nawet jeśli dotyczą one jednego interfejsu ABI, bity lub funkcji sprzętowych, takich jak HWASan (dla każdego interfejsu ABI istnieje oddzielny cel pakietów testowych), nawet jeśli muszą być uruchamiane na danym urządzeniu.
- testy-urządzenia – testy, które opierają się na funkcjach urządzenia.
Zazwyczaj te testy są dostępne w domenie
vendor/
. Termin „właściwy dla urządzenia” nie odnosi się do funkcji ABI czy SoC, które mogą mieć inne urządzenia, lecz do funkcji charakterystycznych dla urządzenia a, dlatego dotyczy ono dokładnie tak wielu testów natywnych GTest, jakgeneral-tests
, nawet jeśli są one związane z interfejsem ABI.
Przykłady:
Android.bp: test_suites: ["general-tests"],
Android.mk: LOCAL_COMPATIBILITY_SUITE := general-tests
Konfigurowanie testów w zestawie testowym
Aby test został uruchomiony w ramach zestawu testów, wykonaj następujące czynności:
- nie może mieć żadnego dostawcy kompilacji.
- należy wyczyścić dane po jego zakończeniu, np. usunąć pliki tymczasowe wygenerowane podczas testu.
- zmienić ustawienia systemu na wartość domyślną lub pierwotną.
- nie powinny zakładać, że urządzenie jest w określonym stanie, np. z dostępem do roota. Większość testów nie wymaga uprawnień roota. Jeśli test musi wymagać uprawnienia użytkownika root, powinien określić, że w parametrze
AndroidTest.xml
jestRootTargetPreparer
, jak w tym przykładzie:
<target_preparer class="com.android.tradefed.targetprep.RootTargetPreparer"/>
Tworzenie testowych plików mapowania
W przypadku katalogu, który wymaga pokrycia testu, wystarczy dodać plik JSON TEST_MAPPING podobny do poniższego przykładu. Te reguły sprawią, że testy będą przeprowadzane w ramach kontroli przed przesłaniem, gdy dotkniesz jakiegoś pliku w tym katalogu lub jego podkatalogach.
Skorzystaj z przykładu
Oto przykładowy plik TEST_MAPPING
(jest on w formacie JSON z obsługą komentarzy):
{
"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"
}
]
}
Ustaw atrybuty
W tym przykładzie presubmit
i postsubmit
to nazwy każdej grupy testowej. Więcej informacji o grupach testowych znajdziesz w artykule Definiowanie grup testowych.
Nazwę modułu testowego lub nazwy testu integracji federacji handlowej (ścieżka zasobu do testowego pliku XML, np. uiautomator/uiautomator-demo) można ustawić w wartości atrybutu name
. Pamiętaj, że pole name nie może używać klasy name
ani metody testowej name
. Aby zawęzić zakres testów, możesz użyć opcji takich jak include-filter
. Patrz przykładowe użycie filtra include.
Ustawienie host testu wskazuje, czy test dotyczy testu bez urządzeń uruchomionego na hoście. Wartość domyślna to false (fałsz), co oznacza, że test wymaga uruchomienia urządzenia. Obsługiwane typy testów to HostGTest w przypadku plików binarnych GTest i HostTest w przypadku testów JUnit.
Atrybut file_patterns umożliwia ustawienie listy ciągów wyrażeń regularnych, które odpowiadają ścieżce względnej dowolnego pliku z kodem źródłowym (względem katalogu zawierającego plik TEST_MAPPING). W powyższym przykładzie test CtsWindowManagerDeviceTestCases
zostanie uruchomiony przed przesłaniem tylko wtedy, gdy jakikolwiek plik Java zaczyna się od tekstu Window lub Activity, który znajduje się w tym samym katalogu co plik TEST_MAPPING lub dowolny z jego podkatalogów. Ukośniki lewe muszą być zmieniane tak, jak w pliku JSON.
Atrybut importy pozwala uwzględnić testy w innych plikach TEST_MAPPING bez kopiowania ich treści. Pamiętaj, że uwzględnione zostaną też pliki TEST_MAPPING w katalogach nadrzędnych zaimportowanej ścieżki. Mapowanie testowe umożliwia importowanie zagnieżdżonych. Oznacza to, że 2 pliki TEST_MAPPING mogą się ze sobą importować, a mapowanie testowe umożliwia prawidłowe scalanie uwzględnionych testów.
Atrybut options zawiera dodatkowe opcje wiersza poleceń TradeFed.
Aby uzyskać pełną listę opcji dostępnych w przypadku danego testu, uruchom polecenie:
tradefed.sh run commandAndExit [test_module] --help
Więcej informacji o działaniu opcji znajdziesz w artykule Obsługa opcji podlegających obrocie w ramach handlu detalicznego .
Przeprowadzanie testów w narzędziu Atest
Aby lokalnie wykonać reguły testu wstępnego:
- Przejdź do katalogu z plikiem TEST_MAPPING.
- Uruchom polecenie:
atest
Uruchomione są wszystkie testy wstępnego przesyłania skonfigurowane w plikach TEST_MAPPING bieżącego katalogu i jego katalogów nadrzędnych. Atest znajdzie i przeprowadzi 2 testy przed przesłaniem (A i B).
To najprostszy sposób wykonywania testów przed przesłaniem plików TEST_MAPPING w bieżącym katalogu roboczym i katalogach nadrzędnych. Atest znajdzie i użyje pliku TEST_MAPPING w CWD i wszystkich jego katalogach nadrzędnych.
Kod źródłowy struktury
Przykład poniżej pokazuje, jak można skonfigurować pliki TEST_MAPPING w drzewie źródłowym.
src
├── project_1
│ └── TEST_MAPPING
├── project_2
│ └── TEST_MAPPING
└── TEST_MAPPING
Treść src/TEST_MAPPING
:
{
"presubmit": [
{
"name": "A"
}
]
}
Treść src/project_1/TEST_MAPPING
:
{
"presubmit": [
{
"name": "B"
}
],
"postsubmit": [
{
"name": "C"
}
],
"other_group": [
{
"name": "X"
}
]}
Treść src/project_2/TEST_MAPPING
:
{
"presubmit": [
{
"name": "D"
}
],
"import": [
{
"path": "src/project_1"
}
]}
Określ katalogi docelowe
Możesz podać katalog docelowy, w którym będziesz przeprowadzać testy w plikach TEST_MAPPING w tym katalogu. Poniższe polecenie uruchomi 2 testy (A i B).
atest --test-mapping src/project_1
Uruchamianie reguł testów po przesłaniu
Możesz też użyć tego polecenia, aby uruchomić reguły testu postsubmit zdefiniowane w zadaniu TEST_MAPPING w środowisku src_path
(domyślnie jest to CWD) i w jego katalogach nadrzędnych:
atest [--test-mapping] [src_path]:postsubmit
Przeprowadzaj tylko testy, które nie wymagają urządzenia
Możesz użyć opcji --host dla Atest, aby uruchomić tylko testy skonfigurowane na hoście niewymagającym urządzenia. Bez tej opcji Atest przeprowadzi oba testy – te, które wymagają urządzenia, oraz te uruchomione na hoście, które nie wymagają urządzenia. Testy odbędą się w 2 osobnych zestawach.
atest [--test-mapping] --host
Określ grupy testowe
Grupy testowe możesz określić w poleceniu Atest. Poniższe 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ć polecenia :all, aby uruchomić wszystkie testy niezależnie od grupy. To polecenie uruchamia 4 testy (A, B, C, X):
atest --test-mapping src/project_1:all
Uwzględnij podkatalogi
Domyślnie testy w trybie TEST_MAPPING z użyciem metody Atest będą uruchamiać tylko testy przed przesłaniem skonfigurowane w pliku TEST_MAPPING w CWD (lub w podanym katalogu) i jego katalogach nadrzędnych. Jeśli chcesz przeprowadzać testy we wszystkich plikach TEST_MAPPING w podkatalogach, użyj opcji --include-subdir
, aby wymusić w Atest uwzględnienie tych testów.
atest --include-subdir
Bez opcji --include-subdir
Atest uruchomi tylko test A. W przypadku opcji --include-subdir
Atest przeprowadzi 2 testy (A i B).
Komentarze na poziomie wiersza są obsługiwane
Możesz dodać komentarz w formacie //
na poziomie wiersza, aby dopracować plik TEST_MAPPING z opisem ustawienia poniżej. ATest i federacja handlu detalicznego przetworzą wstępnie TEST_MAPPING do prawidłowego formatu JSON bez komentarzy. Aby zapewnić czysty i czytelny plik JSON, obsługiwany jest tylko komentarz w formacie //
na poziomie wiersza.
Przykład:
{
// For presubmit test group.
"presubmit": [
{
// Run test on module A.
"name": "A"
}
]
}