Każdy nowy moduł testowy musi mieć plik konfiguracyjny kierujący systemem kompilacji z metadanymi modułu, zależnościami czasu kompilacji i instrukcjami pakowania. Android używa teraz systemu kompilacji Soong w celu prostszej konfiguracji testowej.
Soong używa plików Blueprint lub .bp , które są prostymi, podobnymi do JSON opisami modułów do zbudowania. Ten format zastępuje system oparty na Make używany w poprzednich wydaniach. Szczegółowe informacje można znaleźć w plikach referencyjnych Soong na pulpicie nawigacyjnym ciągłej integracji .
Aby dostosować się do niestandardowego testowania lub użyć pakietu Android Compatibility Test Suite (CTS), postępuj zgodnie z konfiguracją złożonego testu .
Przykład
Poniższe wpisy pochodzą z przykładowego pliku konfiguracyjnego Blueprint: /platform_testing/tests/example/instrumentation/Android.bp
Dla wygody dołączono migawkę:
android_test {
name: "HelloWorldTests",
srcs: ["src/**/*.java"],
sdk_version: "current",
static_libs: ["android-support-test"],
certificate: "platform",
test_suites: ["device-tests"],
}
Zauważ, że deklaracja android_test na początku wskazuje, że jest to test. Dołączenie android_app oznaczałoby odwrotnie, że jest to pakiet kompilacji.
Ustawienia
Następujące ustawienia zbierają wyjaśnienie:
name: "HelloWorldTests",
Ustawienie name jest wymagane w przypadku określenia typu modułu android_test (na początku bloku). Nadaje on nazwę Twojemu modułowi, a wynikowy plik APK będzie miał taką samą nazwę z .apk , np. w tym przypadku wynikowy testowy apk ma nazwę HelloWorldTests.apk . Dodatkowo definiuje to również nazwę docelową make dla twojego modułu, dzięki czemu możesz użyć make [options] <HelloWorldTests> do zbudowania modułu testowego i wszystkich jego zależności.
static_libs: ["android-support-test"],
Ustawienie static_libs instruuje system budowania, aby włączył zawartość nazwanych modułów do wynikowej apk bieżącego modułu. Oznacza to, że każdy nazwany moduł powinien wyprodukować plik .jar , a jego zawartość zostanie użyta do rozwiązania odwołań do ścieżki klas w czasie kompilacji, a także zostanie włączona do wynikowego apk.
W tym przykładzie rzeczy, które mogą być ogólnie przydatne w testach:
android-support-test to wstępnie skompilowana biblioteka obsługi testów systemu Android, która obejmuje nowy program uruchamiający testy AndroidJUnitRunner : zamiennik dla obecnie przestarzałej wbudowanej InstrumentationTestRunner , z obsługą platformy testowej JUnit4. Przeczytaj więcej w Testuj aplikacje na Androida .
Jeśli tworzysz nowy moduł oprzyrządowania, należy zawsze zaczynać od biblioteki android-support-test jako programu uruchamiającego testy. Drzewo źródłowe platformy zawiera również inne przydatne frameworki testowe, takie jak ub-uiautomator , mockito-target , easymock i inne.
certificate: "platform",
Ustawienie certificate instruuje system kompilacji, aby podpisał apk tym samym certyfikatem, co platforma podstawowa. Jest to potrzebne, jeśli Twój test korzysta z uprawnienia lub interfejsu API chronionego podpisem. Należy pamiętać, że jest to odpowiednie do ciągłego testowania platformy, ale nie powinno być używane w modułach testowych CTS. Zwróć uwagę, że ten przykład używa tego ustawienia certyfikatu tylko w celach ilustracyjnych: kod testowy przykładu nie wymaga w rzeczywistości podpisania testowego pakietu apk za pomocą specjalnego certyfikatu platformy.
Jeśli piszesz oprzyrządowanie dla swojego komponentu, który znajduje się poza serwerem systemowym, to znaczy jest spakowany mniej więcej jak zwykły plik apk, z wyjątkiem tego, że jest wbudowany w obraz systemu i może być uprzywilejowaną aplikacją, są szanse, że Twoje oprzyrządowanie będzie kierować się na pakiet aplikacji (patrz poniżej sekcja na temat manifestu) Twojego komponentu. W takim przypadku plik makefile aplikacji może mieć własne ustawienie certificate , a moduł instrumentacji powinien zachować to samo ustawienie. Dzieje się tak dlatego, że aby kierować oprzyrządowanie na testowaną aplikację, testowy pakiet aplikacji i pakiet aplikacji muszą być podpisane tym samym certyfikatem.
W innych przypadkach w ogóle nie musisz mieć tego ustawienia: system kompilacji po prostu podpisze je domyślnym wbudowanym certyfikatem, opartym na wariancie kompilacji i zwykle nazywa się to dev-keys .
test_suites: ["device-tests"],
Ustawienie test_suites sprawia, że test jest łatwo wykrywalny przez uprząż testową Federacji Handlowej. Można tu dodać inne pakiety, takie jak CTS, aby można było udostępnić ten test.
${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk
Ustawienia opcjonalne
Następujące opcjonalne ustawienia zbierają wyjaśnienie:
test_config: "path/to/hello_world_test.xml"
Ustawienie test_config instruuje system kompilacji, w którym cel testu wymaga określonej konfiguracji. Domyślnie plik AndroidTest.xml obok Android.bp jest powiązany z konfiguracją.
auto_gen_config: true
Ustawienie auto_gen_config wskazuje, czy konfiguracja testowa ma zostać utworzona automatycznie. Jeśli AndroidTest.xml nie istnieje obok Android.bp , ten atrybut nie musi być jawnie ustawiony na true.
require_root: true
Ustawienie require_root instruuje system kompilacji, aby dodał RootTargetPreparer do automatycznie wygenerowanej konfiguracji testowej. Gwarantuje to uruchomienie testu z uprawnieniami administratora.
test_min_api_level: 29
Ustawienie test_min_api_level instruuje system kompilacji, aby dodać MinApiLevelModuleController do automatycznie wygenerowanej konfiguracji testu. Gdy Federacja Handlowa uruchomi konfigurację testu, test zostanie pominięty, jeśli właściwość urządzenia ro.product.first_api_level < test_min_api_level .