Konfiguracja prostej kompilacji

Każdy nowy moduł testowy musi mieć plik konfiguracji, który będzie kierował systemem kompilacji z metadanymi modułu, zależnościami czasu kompilowania oraz instrukcjami pakowania. Android korzysta teraz z systemu kompilacji Soong, który ułatwia korzystanie konfigurację testową.

Soong korzysta z plików Blueprint lub .bp, które są prostą deklaracjami deklaratywnymi przypominającymi format JSON. opisy modułów do utworzenia. Ten format zastępuje system oparty na marce używane w poprzednich wersjach. Zobacz pliki referencyjne utworu w panelu ciągłej integracji.

Aby przeprowadzić testy niestandardowe lub skorzystać z Android Compatibility Test Suite (CTS) – postępuj zgodnie z Konfiguracja testu złożonego .

Przykład

Poniższe wpisy pochodzą z tego przykładowego pliku konfiguracji planu: /testy_platformy/testy/przykład/instrumentacja/Android.bp

Dla wygody podajemy tu podsumowanie:

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. Uwzględnienie elementu android_app oznaczałoby, że jest to kompilacja pakietu SDK.

Ustawienia

Wyjaśnienie tych ustawień:

    name: "HelloWorldTests",

Ustawienie name jest wymagane, gdy podany jest typ modułu android_test (na początku bloku). Moduł nadaje mu nazwę, Plik APK będzie miał taką samą nazwę, ale z sufiksem .apk, np. W tym przypadku wynikowy testowy plik APK ma nazwę HelloWorldTests.apk. Dodatkowo, określa docelową nazwę modułu, tak aby możliwe było użycie funkcji make [options] <HelloWorldTests> do utworzenia modułu testowego i wszystkich jego zależności.

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

Ustawienie static_libs instruuje system kompilacji, aby uwzględniał zawartość nazwanych modułów do wynikowego pakietu apk bieżącego modułu. Oznacza to, że każdy nazwany moduł powinien wygenerować plik .jar, a jego zawartość zostanie używane do rozpoznawania odwołań do ścieżek zajęć podczas kompilowania oraz do do wynikowego pliku APK.

Moduł androidx.test.runner jest gotowy do użycia w narzędziu AndroidX Test Runner. Biblioteka zawierająca funkcję uruchamiania testów AndroidJUnitRunner. AndroidJUnitRunner obsługuje platformę testowania JUnit4 i zastępuje ją InstrumentationTestRunner na Androidzie 10. Więcej informacji o testowaniu aplikacji na Androida znajdziesz w artykule Testowanie aplikacji na Androida.

Jeśli tworzysz nowy moduł instrumentacji, zacznij od i użyj biblioteki androidx.test.runner. Drzewo źródłowe platformy zawiera również inne przydatne platformy testowe, takie jak ub-uiautomator, mockito-target, easymock i inne.

    certificate: "platform",

Ustawienie certificate instruuje system kompilacji, aby podpisywał plik APK tym samym kluczem jako podstawowej platformy. Jest to wymagane, jeśli test używa podpisu chronione uprawnienie lub interfejs API. Ten typ sprawdza się w przypadku ciągłej platformy do testowania, ale nie należy jej używać w modułach testowych CTS. Zwróć uwagę, że ten przykład używa tego ustawienia certyfikatu tylko w celach ilustracyjnych: kod testowy nie trzeba w rzeczywistości korzystać z pliku APK podpisanego za pomocą parametru specjalny certyfikat platformy.

Jeśli tworzysz instrumentację dla komponentu, który działa poza serwera systemu, czyli jest mniej lub bardziej jak zwykły plik APK aplikacji, z wyjątkiem tego, że jest wbudowany w obraz systemu i może być aplikacją uprzywilejowaną, że narzędzia są kierowane na pakiet aplikacji (patrz poniżej) o pliku manifestu). W takim przypadku aplikacja Makefile może mieć własne ustawienie certificate, a Twoja instrumentacja powinien zachować to samo ustawienie. Dzieje się tak, ponieważ kierowanie narzędzia w testowanej aplikacji, muszą być podpisane testowe pakiety apk i apk aplikacji z tym samym certyfikatem.

W innych przypadkach to ustawienie jest niepotrzebne. System kompilacji po prostu podpisze go domyślnym, wbudowanym certyfikatem opartym na kompilacji i zwykle nosi on nazwę dev-keys.

    test_suites: ["device-tests"],

Ustawienie test_suites ułatwia znalezienie testu na platformie handlowej Ekstraktor federacji. Można tu dodawać też inne zestawy, np. CTS, test może zostać udostępniony.

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

Ustawienia opcjonalne

Wyjaśnienie tych ustawień opcjonalnych:

    test_config: "path/to/hello_world_test.xml"

Ustawienie test_config instruuje system kompilacji, dla którego testowy cel musi mieć parametr dla danej konfiguracji. Domyślnie obok opcji Android.bp znajduje się ikona AndroidTest.xml powiązane z konfiguracją.

    auto_gen_config: true

Ustawienie auto_gen_config wskazuje, czy należy utworzyć konfigurację testową automatycznie. Jeśli AndroidTest.xml nie istnieje obok Android.bp, to nie trzeba jednoznacznie ustawiać wartości „true” (prawda).

    require_root: true

Ustawienie require_root instruuje system kompilacji, aby dodał element RootTargetPreparer do automatycznie wygenerowanej konfiguracji testowej. Gwarantuje to uruchomienie testu z wykorzystaniem roota uprawnień.

    test_min_api_level: 29

Ustawienie test_min_api_level instruuje system kompilacji, aby dodał MinApiLevelModuleController do automatycznie wygenerowanej konfiguracji testowej. Podczas wymiany Federacja uruchamia konfigurację testową; test zostanie pominięty, jeśli właściwość urządzenia z ro.product.first_api_level < test_min_api_level