Każdy nowy moduł testowy musi mieć plik konfiguracji, który kieruje system kompilacji za pomocą metadanych modułu, zależności w czasie kompilacji i 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 w formacie 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 przykładowego pliku konfiguracji Blueprint: /platform_testing/tests/example/instrumentation/Android.bp
Dla wygody użytkownika zamieszczamy zrzut ekranu:
android_test {
name: "HelloWorldTests",
srcs: ["src/**/*.java"],
sdk_version: "current",
static_libs: ["androidx.test.runner"],
certificate: "platform",
test_suites: ["device-tests"],
}
Pamiętaj, że 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 wynikiem 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 wynikowego pliku APK.
Moduł androidx.test.runner to biblioteka Test Runner dla AndroidX, która zawiera narzędzie do testowania 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 testowania, takie jak ub-uiautomator, mockito-target czy 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 w tym przykładzie 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 takim przypadku makefile aplikacji może mieć własne ustawienie certificate, a twój moduł pomiarowy powinien zachować to samo ustawienie. Dzieje się tak, ponieważ aby kierować ukierunkowanie na potrzeby inżynierii na testowanej aplikacji, 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 testu 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 zostanie uruchomiony z uprawnieniami roota.
test_min_api_level: 29
Ustawienie test_min_api_level instruuje system kompilacji, aby dodał MinApiLevelModuleController do automatycznie wygenerowanej konfiguracji testu. Gdy usługa 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.