Każdy nowy moduł testowy musi mieć plik konfiguracyjny, który będzie sterował systemem kompilacji za pomocą metadanych modułu, zależności w czasie kompilacji i instrukcji pakowania. Android korzysta teraz z systemu kompilacji Soong w celu prostszej konfiguracji testów.
Soong używa plików Blueprint lub .bp , które są prostymi, deklaratywnymi opisami modułów do zbudowania w formacie JSON. Ten format zastępuje system oparty na Make używany w poprzednich wersjach. Aby uzyskać szczegółowe informacje, zobacz pliki referencyjne firmy Soong w panelu ciągłej integracji .
Aby uwzględnić niestandardowe testy lub skorzystać z pakietu testów zgodności systemu Android (CTS), zamiast tego wykonaj złożoną konfigurację 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: ["androidx.test.runner"],
certificate: "platform",
test_suites: ["device-tests"],
}
Zwróć uwagę, że deklaracja android_test na początku wskazuje, że jest to test. Dołączenie android_app wskazywałoby odwrotnie, że jest to pakiet kompilacji.
Ustawienia
Poniższe ustawienia zawierają wyjaśnienie:
name: "HelloWorldTests",
Ustawienie name jest wymagane w przypadku określenia typu modułu android_test (na początku bloku). Nadaje nazwę Twojemu modułowi, a powstały plik APK będzie miał tę samą nazwę i będzie zawierał sufiks .apk , np. w tym przypadku wynikowy plik testowy będzie nosił 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: ["androidx.test.runner"],
Ustawienie static_libs instruuje system kompilacji, aby włączył zawartość nazwanych modułów do wynikowego pliku apk bieżącego modułu. Oznacza to, że oczekuje się, że każdy nazwany moduł wygeneruje plik .jar , a jego zawartość zostanie wykorzystana do rozwiązania odwołań do ścieżek klas podczas kompilacji, a także włączona do wynikowego pliku apk.
Moduł androidx.test.runner to wstępnie skompilowany moduł dla biblioteki AndroidX Test Runner Library, która zawiera moduł uruchamiający testy AndroidJUnitRunner . AndroidJUnitRunner obsługuje platformę testową JUnit4 i zastąpił InstrumentationTestRunner w systemie Android 10. Przeczytaj więcej o testowaniu aplikacji na Androida w artykule Testuj aplikacje na Androidzie .
Jeśli budujesz nowy moduł instrumentacji, powinieneś zawsze zaczynać od biblioteki androidx.test.runner jako modułu uruchamiającego test. Drzewo źródeł platformy zawiera także 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 chronionego podpisem lub interfejsu API. Należy pamiętać, że jest to odpowiednie do ciągłego testowania platformy, ale nie powinno być stosowane w modułach testowych CTS. Należy pamiętać, że w tym przykładzie to ustawienie certyfikatu zostało użyte jedynie w celach ilustracyjnych: kod testowy z przykładu w rzeczywistości nie wymaga podpisania aplikacji testowej specjalnym certyfikatem platformy.
Jeśli piszesz oprzyrządowanie dla swojego komponentu, które znajduje się poza serwerem systemowym, to znaczy jest ono spakowane mniej więcej jak zwykły plik apk aplikacji, z tą różnicą, że jest wbudowane w obraz systemu i może być aplikacją uprzywilejowaną, istnieje prawdopodobieństwo, że Twoje oprzyrządowanie będzie celuj w pakiet aplikacji (patrz sekcja dotycząca manifestu poniżej) swojego 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, ponieważ aby oprzyrządowanie było skierowane na testowaną aplikację, plik testowy i plik aplikacji muszą być podpisane tym samym certyfikatem.
W innych przypadkach nie potrzebujesz w ogóle 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 wiązkę testową Federacji Handlowej. Można tutaj dodać inne pakiety, takie jak CTS, aby można było udostępnić ten test.
${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk
Ustawienia opcjonalne
Poniższe opcjonalne ustawienia zawierają wyjaśnienie:
test_config: "path/to/hello_world_test.xml"
Ustawienie test_config instruuje system kompilacji, że docelowy obiekt testowy potrzebuje określonej konfiguracji. Domyślnie plik AndroidTest.xml obok pliku 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 pliku Android.bp , nie trzeba jawnie ustawiać tego atrybutu na wartość true.
require_root: true
Ustawienie require_root instruuje system kompilacji, aby dodał RootTargetPreparer do automatycznie wygenerowanej konfiguracji testowej. Gwarantuje to uruchomienie testu z uprawnieniami roota.
test_min_api_level: 29
Ustawienie test_min_api_level instruuje system kompilacji, aby dodał MinApiLevelModuleController do automatycznie wygenerowanej konfiguracji testowej. Kiedy Federacja Handlowa uruchomi konfigurację testową, test zostanie pominięty, jeśli właściwość urządzenia ro.product.first_api_level < test_min_api_level .