Prosta konfiguracja kompilacji

Każdy nowy moduł testowy musi mieć plik konfiguracyjny, który zawiera metadane modułu, zależności w czasie kompilacji i instrukcje pakowania. Android używa teraz systemu kompilacji Soong, co upraszcza konfigurację testów.

Soong używa plików Blueprint lub .bp, które są prostymi deklaratywnymi opisami modułów do skompilowania w formacie podobnym do JSON. Ten format zastępuje system Make używany w poprzednich wersjach. Szczegółowe informacje znajdziesz w plikach referencyjnych Soong na panelu ciągłej integracji.

Aby przeprowadzić testy niestandardowe lub użyć pakietu testów zgodności (CTS) na Androida, wykonaj czynności opisane w sekcji Konfiguracja testów złożonych.

Przykład

Poniższe wpisy pochodzą z tego przykładowego pliku konfiguracyjnego planu:/platform_testing/tests/example/instrumentation/Android.bp

Dla wygody dołączyliśmy zrzut ekranu:

android_test {
    name: "HelloWorldTests",
    srcs: ["src/**/*.java"],
    sdk_version: "current",
    static_libs: ["androidx.test.runner"],
    certificate: "platform",
    test_suites: ["device-tests"],
}

Zwróć uwagę na deklarację android_test na początku, która wskazuje, że jest to test. Uwzględnienie android_app wskazuje, że jest to pakiet kompilacji.

Ustawienia

Wyjaśnienia wymagają te ustawienia:

    name: "HelloWorldTests",

Ustawienie name jest wymagane, gdy określony jest typ modułu android_test (na początku bloku). Nadaje ona nazwę modułowi, a wynikowy plik APK będzie miał taką samą nazwę z przyrostkiem .apk, np. w tym przypadku wynikowy testowy plik APK będzie miał nazwę HelloWorldTests.apk. Dodatkowo definiuje to nazwę celu make dla modułu, dzięki czemu możesz użyć polecenia make [options] <HelloWorldTests> do utworzenia modułu testowego i wszystkich jego zależności.

    static_libs: ["androidx.test.runner"],

Ustawienie static_libs nakazuje systemowi kompilacji włączenie zawartości nazwanych modułów do wynikowego pliku APK bieżącego modułu. Oznacza to, że każdy nazwany moduł powinien wygenerować plik .jar, a jego zawartość będzie używana do rozwiązywania odwołań do ścieżki klasy w czasie kompilacji, a także zostanie włączona do wynikowego pliku APK.

Moduł androidx.test.runner jest prekompilowany dla biblioteki AndroidX Test Runner, która zawiera narzędzie do uruchamiania testów AndroidJUnitRunner. AndroidJUnitRunner obsługuje platformę testową JUnit4 i zastąpił InstrumentationTestRunner w Androidzie 10. Więcej informacji o testowaniu aplikacji na Androida znajdziesz w artykule Testowanie aplikacji na Androida.

Jeśli tworzysz nowy moduł instrumentacji, zawsze zaczynaj od biblioteki androidx.test.runner jako narzędzia do uruchamiania testów. Drzewo źródeł platformy zawiera też inne przydatne struktury testowe, takie jak ub-uiautomator, mockito-target, easymock i inne.

    certificate: "platform",

Ustawienie certificate nakazuje systemowi kompilacji podpisanie pliku APK tym samym certyfikatem co platforma podstawowa. Jest to wymagane, jeśli test korzysta z uprawnień lub interfejsu API chronionych podpisem. Pamiętaj, że ta metoda nadaje się do ciągłego testowania platformy, ale nie powinna być używana w modułach testowych CTS. Pamiętaj, że ten przykład używa tego ustawienia certyfikatu tylko w celu ilustracyjnym: kod testowy w przykładzie nie wymaga, aby testowy plik APK był podpisany specjalnym certyfikatem platformy.

Jeśli piszesz instrumentację dla komponentu, który znajduje się poza serwerem systemowym, czyli jest spakowany mniej więcej jak zwykły plik APK aplikacji, z tą różnicą, że jest wbudowany w obraz systemu i może być aplikacją uprzywilejowaną, prawdopodobnie będzie ona kierowana na pakiet aplikacji (patrz sekcja poniżej dotycząca pliku 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, ponieważ aby kierować instrumentację na testowaną aplikację, plik APK testu i plik APK aplikacji muszą być podpisane tym samym certyfikatem.

W innych przypadkach to ustawienie nie jest potrzebne: system kompilacji po prostu 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 łatwo wykrywalny przez platformę testową Trade Federation. Można tu dodać inne zestawy, np. CTS, aby można było udostępnić ten test.

${ANDROID_PRODUCT_OUT}/testcases/HelloWorldTests/HelloWorldTests.apk

Ustawienia opcjonalne

Wyjaśnienia wymagają te opcjonalne ustawienia:

    test_config: "path/to/hello_world_test.xml"

Ustawienie test_config informuje system kompilacji, że docelowy test wymaga określonej konfiguracji. Domyślnie obok Android.bp znajduje się AndroidTest.xml, które jest powiązane z konfiguracją.

    auto_gen_config: true

Ustawienie auto_gen_config określa, czy konfiguracja testu ma być tworzona automatycznie. Jeśli obok Android.bp nie ma AndroidTest.xml, nie musisz jawnie ustawiać tego atrybutu na wartość „true”.

    require_root: true

Ustawienie require_root nakazuje systemowi kompilacji dodanie do automatycznie wygenerowanej konfiguracji testu elementu RootTargetPreparer. Gwarantuje to przeprowadzenie testu z uprawnieniami roota.

    test_min_api_level: 29

Ustawienie test_min_api_level nakazuje systemowi kompilacji dodanie elementu MinApiLevelModuleController do automatycznie wygenerowanej konfiguracji testu. Gdy Trade Federation uruchomi konfigurację testu, test zostanie pominięty, jeśli właściwość urządzenia ro.product.first_api_level < test_min_api_level.