Każdy nowy moduł testowy musi mieć plik konfiguracji, który będzie przekazywać systemowi kompilacji za pomocą metadanych modułu, zależności podczas kompilowania oraz instrukcji 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ą prostym, deklaratywnym opisem modułów do skompilowania, podobnym do JSON. Ten format zastępuje system oparty na make, który był używany w poprzednich wersjach. Więcej informacji znajdziesz w plikach referencyjnych Songa na panelu integracji ciągłej.
Aby przeprowadzić testy niestandardowe lub użyć Compatibility Test Suite (CTS) na Androida, 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
Dla wygody użytkownika zamieszczamy tutaj zrzut ekranu:
android_test {
name: "HelloWorldTests",
srcs: ["src/**/*.java"],
sdk_version: "current",
static_libs: ["androidx.test.runner"],
certificate: "platform",
test_suites: ["device-tests"],
}
Deklaracja android_test na początku wskazuje, że jest to test.
Dodanie android_app oznaczałoby, że jest to pakiet kompilacji.
Ustawienia
Wyjaśnienie tych ustawień:
name: "HelloWorldTests",
Ustawienie name jest wymagane, gdy określony jest typ modułu android_test (na początku bloku). Nadaje nazwę modułowi, a wygenerowany plik APK będzie miał taką samą nazwę z przyrostkiem .apk. W tym przypadku wygenerowany plik APK testu ma nazwę HelloWorldTests.apk. Dodatkowo definiuje on nazwę docelową make dla modułu, dzięki czemu możesz użyć make [options]
<HelloWorldTests> do skompilowania modułu testowego i wszystkich jego zależności.
static_libs: ["androidx.test.runner"],
Ustawienie static_libs instruuje system kompilacji, aby uwzględnić zawartość wymienionych modułów w wygenerowanym pliku APK bieżącego modułu. Oznacza to, że każdy moduł z nazwą powinien wygenerować plik .jar, którego zawartość będzie używana do rozwiązywania odwołań do ścieżki klasy podczas kompilacji, a także zostanie włączona do utworzonego pliku APK.
Moduł androidx.test.runner to gotowy moduł uruchamiający testy AndroidaX, który zawiera program uruchamiający testy AndroidJUnitRunner.
AndroidJUnitRunner obsługuje framework testowy JUnit4 i zastąpiła InstrumentationTestRunner w Androidzie 10. Więcej informacji o testowaniu aplikacji na Androida znajdziesz w artykule Testowanie aplikacji na Androida.
Jeśli tworzysz nowy moduł pomiarowy, zawsze zaczynaj od biblioteki androidx.test.runner jako narzędzia do testowania. Drzewo źródeł platformy zawiera też inne przydatne ramy testowe, takie jak ub-uiautomator, mockito-target i easymock.
certificate: "platform",
Ustawienie certificate instruuje system kompilacji, aby plik APK został podpisany tym samym certyfikatem co platforma główna. Jest to konieczne, jeśli test używa uprawnienia lub interfejsu API chronionego podpisem cyfrowym. Pamiętaj, że ta metoda jest odpowiednia do ciągłego testowania platformy, ale nie powinna być używana w modułach testów CTS. Pamiętaj, że w tym przykładzie ustawienie certyfikatu jest używane tylko do celów poglądowych: kod testowy nie wymaga, aby testowy plik APK był podpisany specjalnym certyfikatem platformy.
Jeśli piszesz instrumentację dla komponentu, który działa poza serwerem systemowym, czyli jest spakowany mniej więcej jak zwykły plik APK aplikacji, z tym że jest wbudowany w obraz systemu i może być aplikacją uprzywilejowaną, to prawdopodobnie Twoja instrumentacja będzie kierować się na pakiet aplikacji (patrz sekcja o pliku manifestu poniżej) Twojego komponentu. W tym przypadku plik Makefile aplikacji może mieć własne ustawienie certificate, a moduł instrumentacji powinien zachować to samo ustawienie. Dzieje się tak, ponieważ aby kierować inżynierię na testowaną aplikację, plik APK testowy i plik APK aplikacji muszą być podpisane tym samym certyfikatem.
W innych przypadkach nie musisz wcale używać tego ustawienia: system kompilacji podpisze go domyślnym wbudowanym certyfikatem na podstawie wariantu kompilacji. Zwykle nazywa się on dev-keys.
test_suites: ["device-tests"],
Ustawienie test_suites sprawia, że test jest łatwy do znalezienia przez narzędzie testowe Trade Federation. Możesz tu dodać inne pakiety, na przykład CTS, aby udostępnić ten test.
${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk
Ustawienia opcjonalne
Wyjaśnienie tych opcjonalnych ustawień:
test_config: "path/to/hello_world_test.xml"
Ustawienie test_config informuje system kompilacji, że docelowy obiekt testowy wymaga określonej konfiguracji. Domyślnie z konfiguracją jest powiązany element AndroidTest.xml obok elementu Android.bp.
auto_gen_config: true
Ustawienie auto_gen_config wskazuje, czy konfiguracja testu ma być tworzona automatycznie. Jeśli AndroidTest.xml nie występuje obok Android.bp, nie musisz jawnie ustawiać tego atrybutu na wartość prawda.
require_root: true
Ustawienie require_root instruuje system kompilacji, aby dodał RootTargetPreparer do automatycznie wygenerowanej konfiguracji testu. Dzięki temu test będzie wykonywany z uprawnieniami roota.
test_min_api_level: 29
Ustawienie test_min_api_level instruuje system kompilacji, aby do automatycznie wygenerowanej konfiguracji testu dodał MinApiLevelModuleController. Gdy usługa Trade Federation uruchomi konfigurację testową, test zostanie pominięty, jeśli właściwość urządzenia ro.product.first_api_level < test_min_api_level.