Każdy nowy moduł testowy musi mieć plik konfiguracyjny do kierowania systemem kompilacji z metadanymi modułu, zależnościami w czasie kompilacji i instrukcjami dotyczącymi pakowania. Android używa teraz systemu kompilacji Soong w celu uproszczenia konfiguracji testów.
Soong używa plików Blueprint lub .bp , które są podobnymi do formatu JSON prostymi deklaratywnymi opisami modułów do zbudowania. Ten format zastępuje system oparty na Make, używany w poprzednich wersjach. Zobacz pliki referencyjne Soong na pulpicie nawigacyjnym Continuous Integration, aby uzyskać szczegółowe informacje.
Aby dostosować się do testów niestandardowych lub skorzystać z zestawu testów zgodności z systemem Android (CTS), postępuj zgodnie z konfiguracją testu złożonego .
Przykład
Poniższe wpisy pochodzą z tego przykładowego pliku konfiguracyjnego Blueprint: /platform_testing/tests/example/instrumentation/Android.bp
Migawka jest tutaj dla wygody:
android_test {
name: "HelloWorldTests",
srcs: ["src/**/*.java"],
sdk_version: "current",
static_libs: ["androidx.test.runner"],
certificate: "platform",
test_suites: ["device-tests"],
}
Zauważ, że deklaracja android_test na początku wskazuje, że jest to test. Włączenie android_app odwrotnie wskazywałoby, że jest to pakiet kompilacji.
Ustawienia
Poniższe ustawienia gromadzą wyjaśnienie:
name: "HelloWorldTests",
Ustawienie name jest wymagane, gdy określony jest typ modułu android_test (na początku bloku). Nadaje nazwę twojemu modułowi, a wynikowy plik APK będzie miał taką samą nazwę i będzie zawierał sufiks .apk , np. w tym przypadku wynikowy testowy apk nosi nazwę HelloWorldTests.apk . Ponadto definiuje to również nazwę celu 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ł utworzy plik .jar , a jego zawartość zostanie wykorzystana do rozwiązania odwołań do ścieżki klasy w czasie kompilacji, a także włączona do wynikowego pliku APK.
Moduł androidx.test.runner to wstępnie skompilowany moduł AndroidX Test Runner Library, który zawiera program 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 Testuj aplikacje na Androida .
Jeśli tworzysz nowy moduł oprzyrządowania, powinieneś zawsze zaczynać od biblioteki androidx.test.runner jako elementu uruchamiającego testy. Drzewo źródeł 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 w teście używane jest uprawnienie lub interfejs API chronione sygnaturami. Należy zauważyć, że jest to odpowiednie do ciągłego testowania platformy, ale nie powinno być używane w modułach testowych CTS. Zwróć uwagę, że w tym przykładzie to ustawienie certyfikatu jest używane tylko w celach ilustracyjnych: kod testowy w przykładzie nie wymaga w rzeczywistości podpisywania testowej aplikacji za pomocą specjalnego certyfikatu platformy.
Jeśli piszesz instrumentację dla swojego komponentu, która znajduje się poza serwerem systemowym, to znaczy jest spakowana mniej więcej tak, jak zwykły apk aplikacji, z wyjątkiem tego, że jest wbudowana w obraz systemu i może być aplikacją uprzywilejowaną, są szanse, że twoja instrumentacja kierować reklamy na pakiet aplikacji (zobacz poniżej sekcję dotyczącą manifestu) swojego komponentu. W takim przypadku plik makefile aplikacji może mieć własne ustawienie certificate , a moduł instrumentacji powinien zachować to samo ustawienie. Wynika to z faktu, że aby kierować instrumentację na testowaną aplikację, testowy plik APK i plik APK 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 na podstawie wariantu 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. Tutaj można dodać inne pakiety, takie jak CTS, aby ten test mógł być udostępniany.
${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk
Ustawienia opcjonalne
Poniższe opcjonalne ustawienia gromadzą wyjaśnienie:
test_config: "path/to/hello_world_test.xml"
Ustawienie test_config instruuje system kompilacji, że twój cel 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 testu ma być tworzona 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 testu. 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 generowanej konfiguracji testu. Gdy 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 .
Każdy nowy moduł testowy musi mieć plik konfiguracyjny do kierowania systemem kompilacji z metadanymi modułu, zależnościami w czasie kompilacji i instrukcjami dotyczącymi pakowania. Android używa teraz systemu kompilacji Soong w celu uproszczenia konfiguracji testów.
Soong używa plików Blueprint lub .bp , które są podobnymi do formatu JSON prostymi deklaratywnymi opisami modułów do zbudowania. Ten format zastępuje system oparty na Make, używany w poprzednich wersjach. Zobacz pliki referencyjne Soong na pulpicie nawigacyjnym Continuous Integration, aby uzyskać szczegółowe informacje.
Aby dostosować się do testów niestandardowych lub skorzystać z zestawu testów zgodności z systemem Android (CTS), postępuj zgodnie z konfiguracją testu złożonego .
Przykład
Poniższe wpisy pochodzą z tego przykładowego pliku konfiguracyjnego Blueprint: /platform_testing/tests/example/instrumentation/Android.bp
Migawka jest tutaj dla wygody:
android_test {
name: "HelloWorldTests",
srcs: ["src/**/*.java"],
sdk_version: "current",
static_libs: ["androidx.test.runner"],
certificate: "platform",
test_suites: ["device-tests"],
}
Zauważ, że deklaracja android_test na początku wskazuje, że jest to test. Włączenie android_app odwrotnie wskazywałoby, że jest to pakiet kompilacji.
Ustawienia
Poniższe ustawienia gromadzą wyjaśnienie:
name: "HelloWorldTests",
Ustawienie name jest wymagane, gdy określony jest typ modułu android_test (na początku bloku). Nadaje nazwę twojemu modułowi, a wynikowy plik APK będzie miał taką samą nazwę i będzie zawierał sufiks .apk , np. w tym przypadku wynikowy testowy apk nosi nazwę HelloWorldTests.apk . Ponadto definiuje to również nazwę celu 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ł utworzy plik .jar , a jego zawartość zostanie wykorzystana do rozwiązania odwołań do ścieżki klasy w czasie kompilacji, a także włączona do wynikowego pliku APK.
Moduł androidx.test.runner to wstępnie skompilowany moduł AndroidX Test Runner Library, który zawiera program 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 Testuj aplikacje na Androida .
Jeśli tworzysz nowy moduł oprzyrządowania, powinieneś zawsze zaczynać od biblioteki androidx.test.runner jako elementu uruchamiającego testy. Drzewo źródeł 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 w teście używane jest uprawnienie lub interfejs API chronione sygnaturami. Należy zauważyć, że jest to odpowiednie do ciągłego testowania platformy, ale nie powinno być używane w modułach testowych CTS. Zwróć uwagę, że w tym przykładzie to ustawienie certyfikatu jest używane tylko w celach ilustracyjnych: kod testowy w przykładzie nie wymaga w rzeczywistości podpisywania testowej aplikacji za pomocą specjalnego certyfikatu platformy.
Jeśli piszesz instrumentację dla swojego komponentu, która znajduje się poza serwerem systemowym, to znaczy jest spakowana mniej więcej tak, jak zwykły apk aplikacji, z wyjątkiem tego, że jest wbudowana w obraz systemu i może być aplikacją uprzywilejowaną, są szanse, że twoja instrumentacja kierować reklamy na pakiet aplikacji (zobacz poniżej sekcję dotyczącą manifestu) swojego komponentu. W takim przypadku plik makefile aplikacji może mieć własne ustawienie certificate , a moduł instrumentacji powinien zachować to samo ustawienie. Wynika to z faktu, że aby kierować instrumentację na testowaną aplikację, testowy plik APK i plik APK 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 na podstawie wariantu 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. Tutaj można dodać inne pakiety, takie jak CTS, aby ten test mógł być udostępniany.
${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk
Ustawienia opcjonalne
Poniższe opcjonalne ustawienia gromadzą wyjaśnienie:
test_config: "path/to/hello_world_test.xml"
Ustawienie test_config instruuje system kompilacji, że twój cel 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 testu ma być tworzona 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 testu. 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 generowanej konfiguracji testu. Gdy 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 .
Każdy nowy moduł testowy musi mieć plik konfiguracyjny do kierowania systemem kompilacji z metadanymi modułu, zależnościami w czasie kompilacji i instrukcjami dotyczącymi pakowania. Android używa teraz systemu kompilacji Soong w celu uproszczenia konfiguracji testów.
Soong używa plików Blueprint lub .bp , które są podobnymi do formatu JSON prostymi deklaratywnymi opisami modułów do zbudowania. Ten format zastępuje system oparty na Make, używany w poprzednich wersjach. Zobacz pliki referencyjne Soong na pulpicie nawigacyjnym Continuous Integration, aby uzyskać szczegółowe informacje.
Aby dostosować się do testów niestandardowych lub skorzystać z zestawu testów zgodności z systemem Android (CTS), postępuj zgodnie z konfiguracją testu złożonego .
Przykład
Poniższe wpisy pochodzą z tego przykładowego pliku konfiguracyjnego Blueprint: /platform_testing/tests/example/instrumentation/Android.bp
Migawka jest tutaj dla wygody:
android_test {
name: "HelloWorldTests",
srcs: ["src/**/*.java"],
sdk_version: "current",
static_libs: ["androidx.test.runner"],
certificate: "platform",
test_suites: ["device-tests"],
}
Zauważ, że deklaracja android_test na początku wskazuje, że jest to test. Włączenie android_app odwrotnie wskazywałoby, że jest to pakiet kompilacji.
Ustawienia
Poniższe ustawienia gromadzą wyjaśnienie:
name: "HelloWorldTests",
Ustawienie name jest wymagane, gdy określony jest typ modułu android_test (na początku bloku). Nadaje nazwę twojemu modułowi, a wynikowy plik APK będzie miał taką samą nazwę i będzie zawierał sufiks .apk , np. w tym przypadku wynikowy testowy apk nosi nazwę HelloWorldTests.apk . Ponadto definiuje to również nazwę celu 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ł utworzy plik .jar , a jego zawartość zostanie wykorzystana do rozwiązania odwołań do ścieżki klasy w czasie kompilacji, a także włączona do wynikowego pliku APK.
Moduł androidx.test.runner to wstępnie skompilowany moduł AndroidX Test Runner Library, który zawiera program 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 Testuj aplikacje na Androida .
Jeśli tworzysz nowy moduł oprzyrządowania, powinieneś zawsze zaczynać od biblioteki androidx.test.runner jako elementu uruchamiającego testy. Drzewo źródeł 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 w teście używane jest uprawnienie lub interfejs API chronione sygnaturami. Należy zauważyć, że jest to odpowiednie do ciągłego testowania platformy, ale nie powinno być używane w modułach testowych CTS. Zwróć uwagę, że w tym przykładzie to ustawienie certyfikatu jest używane tylko w celach ilustracyjnych: kod testowy w przykładzie nie wymaga w rzeczywistości podpisywania testowej aplikacji za pomocą specjalnego certyfikatu platformy.
Jeśli piszesz instrumentację dla swojego komponentu, która znajduje się poza serwerem systemowym, to znaczy jest spakowana mniej więcej tak, jak zwykły apk aplikacji, z wyjątkiem tego, że jest wbudowana w obraz systemu i może być aplikacją uprzywilejowaną, są szanse, że twoja instrumentacja kierować reklamy na pakiet aplikacji (zobacz poniżej sekcję dotyczącą manifestu) swojego komponentu. W takim przypadku plik makefile aplikacji może mieć własne ustawienie certificate , a moduł instrumentacji powinien zachować to samo ustawienie. Wynika to z faktu, że aby kierować instrumentację na testowaną aplikację, testowy plik APK i plik APK 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 na podstawie wariantu 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. Tutaj można dodać inne pakiety, takie jak CTS, aby ten test mógł być udostępniany.
${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk
Ustawienia opcjonalne
Poniższe opcjonalne ustawienia gromadzą wyjaśnienie:
test_config: "path/to/hello_world_test.xml"
Ustawienie test_config instruuje system kompilacji, że twój cel 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 testu ma być tworzona 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 testu. 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 generowanej konfiguracji testu. Gdy 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 .