Prosta konfiguracja kompilacji

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 teraz korzysta z kompilacji systemu Soong łatwiejszej konfiguracji testowej.

Soong wykorzystuje Blueprint lub .bp plików JSON, które są podobne do prostych deklaratywnych opisów modułów zbudować. Ten format zastępuje system oparty na Make używany w poprzednich wydaniach. Zobacz pliki referencyjne soong na Continuous Integration Dashboard dla pełnych szczegółów.

Aby pomieścić niestandardowe badania lub skorzystać z Androidem Compatibility Test Suite (CTS), wykonaj konfiguracji testowej Complex zamiast.

Przykład

Poniższe wpisy pochodzą z tym przykładowym pliku konfiguracyjnym 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"],
}

Zwróć uwagę na android_test deklarację na początku wskazuje, że jest to próba. W tym android_app byłoby odwrotnie wskazuje to zamiast pakiet build.

Ustawienia

Następujące ustawienia zbierają wyjaśnienia:

    name: "HelloWorldTests",

name ustawienie jest wymagane, gdy android_test typ modułu danych (na początku bloku). Daje nazwę modułu, a otrzymaną APK zostanie nazwany tak samo iz .apk przyrostkiem, np w tym przypadku, w wyniku apk test nazwany HelloWorldTests.apk . Ponadto ten określa również make nazwę docelową dla modułu, dzięki czemu można korzystać z make [options] <HelloWorldTests> zbudować moduł testowy i wszystkie jego zależności.

    static_libs: ["android-support-test"],

W static_libs ustawienie powoduje włączenie systemu budowy zawartość wymienionych modułów do otrzymanego apk modułu prądu. Oznacza to, że oczekuje się Nazwa każdego modułu do wytwarzania .jar plik i jego zawartość będzie używane do rozwiązywania odniesienia Classpath podczas kompilacji, jak również włączone do otrzymanego apk.

W tym przykładzie rzeczy, które mogą być ogólnie przydatne w testach:

android-support-test jest Montowane na Androida testowym Wsparcia Library, która zawiera nowe testy biegacz AndroidJUnitRunner : zamiennik teraz przestarzałe wbudowaną InstrumentationTestRunner , ze wsparciem dla JUnit4 ramach testów. Czytaj więcej w aplikacjach testowych na Androida .

Jeśli budujesz nowy moduł oprzyrządowania, należy zawsze rozpocząć z android-support-test biblioteki jako swojej testowej biegacza. Drzewo źródłowe platforma zawiera również inne przydatne testowania ram takich jak ub-uiautomator , mockito-target , easymock i więcej.

    certificate: "platform",

certificate ustawienie instruuje system budowania podpisać apk tym samym certyfikatem jako platformy bazowej. Jest to potrzebne, jeśli Twój test korzysta z uprawnienia lub interfejsu API chronionego podpisem. Należy pamiętać, że jest to korzystne dla platformy ciągłego testowania, ale nie powinny być wykorzystywane w modułach testowych CTS. Zwróć uwagę, że ten przykład używa tego ustawienia certyfikatu tylko w celach ilustracyjnych: kod testowy przykładu w rzeczywistości nie wymaga 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 być kierowane na pakiet aplikacji (patrz poniżej sekcja na temat manifestu) Twojego komponentu. W tym przypadku, twój makefile aplikacja może mieć swój własny certificate ustawienie, a moduł oprzyrządowanie powinny zachować te same ustawienia. 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, nie trzeba mieć to ustawienie w ogóle: system build będzie po prostu podpisać z domyślnie wbudowane w certyfikacie, w oparciu o wariant budowy, i to zazwyczaj nazywane dev-keys .

    test_suites: ["device-tests"],

test_suites ustawienie sprawia, że test łatwo wykrywalnego przez uprzęży testu 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"

test_config ustawienie instruuje system zbudować swój cel testu potrzeb konkretnego config. Domyślnie każdy AndroidTest.xml obok Android.bp jest związany z config.

    auto_gen_config: true

auto_gen_config ustawienie wskazuje, czy nie stworzyć config testowego automatycznie. Jeśli AndroidTest.xml nie istnieje obok Android.bp , atrybut ten nie musi być ustawiona na true wyraźnie.

    require_root: true

require_root ustawienie instruuje system budowania, aby dodać RootTargetPreparer do testu auto generowane config. Gwarantuje to uruchomienie testu z uprawnieniami roota.

    test_min_api_level: 29

test_min_api_level ustawienie instruuje system budowania, aby dodać MinApiLevelModuleController do testu auto generowane config. Kiedy Federacja Handlowa prowadzi config testu, test zostanie pominięty, jeżeli nieruchomość urządzenie ro.product.first_api_level < test_min_api_level .