Zaawansowana konfiguracja testu

Artykuł Testowanie w Android Studio i Testowanie z poziomu wiersza poleceń wyjaśniają, jak przygotowywać i uruchamiać podstawowe konfiguracje testowe. Jednak gdy Twoja aplikacja i jej wymagania testowe staną się bardziej zaawansowane, konieczne może być dalsze dostosowanie konfiguracji testów. Zaawansowana konfiguracja testów może być potrzebna np. wtedy, gdy chcesz:

• Przeprowadzaj testy instrumentalne tylko dla określonego wariantu kompilacji lub zastąp ustawienia w jego pliku manifestu.
• Zmień typ kompilacji, na którym są wykonywane testy, lub skonfiguruj jego opcje Gradle.
• Wyodrębnij testy z instrumentowane do osobnego modułu testowego.
• Przeprowadź bardziej zaawansowane testy w ramach konfiguracji ciągłej integracji.

Na tej stronie opisujemy różne sposoby konfigurowania testów, gdy domyślne ustawienia nie odpowiadają Twoim potrzebom.

Tworzenie testu instrumentowanego dla wariantu kompilacji

Jeśli Twój projekt obejmuje warianty kompilacji z unikalnymi zbiorami źródłowymi, możesz uwzględnić testy instrumentowane, które odpowiadają tym zbiorom źródłowym. Pozwala to zachować porządek w kodzie testowym i umożliwia uruchamianie tylko tych testów, które dotyczą danego wariantu kompilacji.

Aby połączyć testy instrumentowane z wariantem kompilacji, umieść je w osobnym zbiorze źródłowym w src/androidTestVariantName.

Testy z instrumentów w zbiorze źródłowym src/androidTest/ są używane przez wszystkie warianty kompilacji. Podczas tworzenia testowego pakietu APK dla wariantu aplikacji „MyFlavor” Gradle łączy zestawy źródłowe src/androidTest/ i src/androidTestMyFlavor/.

Aby dodać zestaw źródeł testowych do wariantu kompilacji w Android Studio, wykonaj te czynności:

1. W oknie Projekt kliknij menu i wybierz widok Projekt.
2. W odpowiednim folderze modułu kliknij prawym przyciskiem myszy folder src, a następnie Nowy > Katalog.
3. Jako nazwę katalogu wpisz „androidTestVariantName”. Jeśli na przykład masz wariant kompilacji o nazwie „MójSmak”, użyj nazwy katalogu androidTestMyFlavor.
4. Kliknij OK.
5. Kliknij nowy katalog prawym przyciskiem myszy i wybierz Nowy > Katalog.
6. Jako nazwę katalogu wpisz „java” i kliknij OK.

Możesz teraz dodawać testy do nowego zbioru źródłowego, wykonując te czynności. Gdy dojdziesz do okna Wybierz katalog docelowy, wybierz nowy testowy zbiór źródeł wariantów.

W tabeli poniżej znajdziesz przykład tego, jak pliki testowe z instrumentacją mogą się znajdować w zbiorach źródłowych odpowiadających zbiorom źródłowym kodu aplikacji:

Tabela 1. Kod źródłowy aplikacji i odpowiadające im pliki testowe narzędzi

Tak jak w przypadku zbiorów źródłowych aplikacji, kompilacja Gradle scala i zastępuje pliki z różnych testowych zbiorów źródłowych. W tym przypadku plik AndroidExampleTest.java w zbiorze źródłowym androidTestMyFlavor zastępuje wersję w zbiorze źródłowym androidTest. Dzieje się tak, ponieważ zestaw źródeł smaków produktu ma wyższy priorytet niż główny zestaw źródłowy.

Jeśli w selektorze wariantów kompilacji wybierzesz różne smaki, w widoku Android wyświetlą się odpowiednie foldery androidTest, gdzie będą widoczne używane foldery:

Folder androidTestMyFlavor nie wyświetla się, gdy wybrano inną wersję:

Wygląda to nieco inaczej w widoku Projekt, ale obowiązuje ta sama zasada:

Po wybraniu innej wersji folder androidTestMyFlavor pozostaje widoczny, ale nie jest widoczny jako aktywny:

Więcej informacji o scalaniu zbiorów źródłowych znajdziesz w sekcji Zbiory źródłowe.

Skonfiguruj ustawienia pliku manifestu narzędzi

Testy z instrumentów są wbudowane w oddzielny plik APK z własnym plikiem AndroidManifest.xml. Gdy Gradle skompiluje testowy pakiet APK, automatycznie generuje plik AndroidManifest.xml i konfiguruje go w węźle <instrumentation>. Jednym z powodów, dla których Gradle konfiguruje ten węzeł za Ciebie, jest sprawdzenie, czy właściwość targetPackage określa prawidłową nazwę pakietu testowanej aplikacji.

Aby zmienić inne ustawienia dla tego węzła, utwórz kolejny plik manifestu w testowym zestawie źródłowym lub skonfiguruj plik build.gradle na poziomie modułu, jak pokazano w poniższym przykładowym kodzie. Pełną listę opcji znajdziesz w dokumentacji interfejsu API BaseFlavor.

android {
    ...
    defaultConfig {
        ...
        testApplicationId "com.example.test"
        testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
        testHandleProfiling true
        testFunctionalTest true
    }
}

android {
    ...
    defaultConfig {
        ...
        testApplicationId = "com.example.test"
        testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
        testHandleProfiling = true
        testFunctionalTest = true
    }
}

Each product flavor you configure can override properties in the defaultConfig {} block. To learn more, go to Configure product flavors.

The properties in the snippet are:

Change the test build type

By default, all instrumentation tests run against the debug build type. You can change this to another build type by using the testBuildType property in your module-level build.gradle file. For example, if you want to run your tests against your staging build type, edit the file as shown in the following snippet:

android {
    ...
    testBuildType "staging"
}

android {
    ...
    testBuildType = "staging"
}

Skonfiguruj opcje testu Gradle

Wtyczka Androida do obsługi Gradle umożliwia określenie opcji we wszystkich lub tylko w przypadku niektórych testów. W pliku build.gradle na poziomie modułu użyj bloku testOptions, aby określić opcje, które zmieniają sposób uruchamiania wszystkich testów przez Gradle:

android {
    ...
    // Encapsulates options for running tests.
    testOptions {
        reportDir "$rootDir/test-reports"
        resultsDir "$rootDir/test-results"
    }
}

android {
    ...
    // Encapsulates options for running tests.
    testOptions {
        reportDir "$rootDir/test-reports"
        resultsDir = "$rootDir/test-results"
    }
}

Właściwość reportDir zmienia katalog, w którym Gradle zapisuje raporty testowe. Domyślnie Gradle zapisuje raporty testowe w katalogu path_to_your_project/module_name /build/outputs/reports/. $rootDir określa ścieżkę względną do katalogu głównego bieżącego projektu.

Właściwość resultsDir zmienia katalog, w którym Gradle zapisuje wyniki testów. Domyślnie Gradle zapisuje wyniki testu w katalogu path_to_your_project/module_name /build/outputs/test-results/. $rootDir określa ścieżkę względną do katalogu głównego bieżącego projektu.

Aby określić opcje tylko dla testów jednostkowych lokalnych, skonfiguruj blok unitTests w testOptions.

android {
    ...
    testOptions {
        ...
        // Encapsulates options for local unit tests.
        unitTests {
            returnDefaultValues true

            all {
                jvmArgs '-XX:MaxPermSize=256m'

                if (it.name == 'testDebugUnitTest') {
                    systemProperty 'debug', 'true'
                }
                ...
            }
        }
    }
}

android {
    ...
    testOptions {
        ...
        // Encapsulates options for local unit tests.
        unitTests {
            returnDefaultValues = true

            all {
                jvmArgs = listOf("-XX:MaxPermSize=256m")

                 if (it.name == "testDebugUnitTest") {
                    systemProperty = mapOf("debug" to "true")
                }
                ...
            }
        }
    }
}

Domyślnie testy jednostek lokalnych zgłaszają wyjątek za każdym razem, gdy testowany kod próbuje uzyskać dostęp do interfejsów API platformy Androida, chyba że imitujesz zależności Androida samodzielnie lub za pomocą platformy testowej takiej jak Mockito. Możesz jednak włączyć właściwość returnDefaultValues, tak aby podczas uzyskiwania dostępu do interfejsów API platformy test zwracał wartość null lub 0, zamiast zgłaszać wyjątek.

Blok all zawiera opcje umożliwiające kontrolowanie sposobu wykonywania przez Gradle testów jednostek lokalnych. Listę wszystkich opcji, które można określić, znajdziesz w dokumentacji referencyjnej Gradle.

Właściwość jvmArgs ustawia argumenty JVM dla testowych JVM.

Możesz też sprawdzić nazwę zadania, aby zastosować opcje tylko do określonych testów. W przykładowym fragmencie kodu właściwość debug jest ustawiona na true, ale tylko w przypadku zadania testDebugUnitTest.

Używanie osobnych modułów testowych na potrzeby testów z instrumentacją

Jeśli chcesz mieć specjalny moduł na potrzeby testów z instrumentacją, aby odizolować od testów pozostałe fragmenty kodu, utwórz osobny moduł testowy i skonfiguruj jego kompilację podobnie do modułu biblioteki.

Aby utworzyć moduł testowy, wykonaj następujące czynności:

1. Utwórz moduł biblioteki.
2. W pliku build.gradle na poziomie modułu zastosuj wtyczkę com.android.test zamiast com.android.library.
3. Kliknij Synchronizuj projekt .

Po utworzeniu modułu testowego możesz umieścić kod testowy w głównym zestawie źródłowym lub w zestawie źródłowym (np. src/main/java lub src/variant/java). Jeśli moduł aplikacji definiuje wiele smaków produktów, możesz odtworzyć te smaki w module testowym. Za pomocą zarządzania zależnościami z uwzględnieniem wariantów moduł testowy próbuje przetestować pasujący rodzaj w module docelowym.

Domyślnie moduły testowe zawierają i testują tylko wariant do debugowania. Możesz jednak tworzyć nowe typy kompilacji pasujące do testowanego projektu aplikacji. Aby ustawić w module testowym inny typ kompilacji, a nie tę, użyj funkcji VariantFilter do wyłączenia wariantu debugowania w projekcie testowym:

android {
    variantFilter { variant ->
        if (variant.buildType.name.equals('debug')) {
            variant.setIgnore(true);
        }
    }
}

android {
    variantFilter {
        if (buildType.name == "debug") {
            ignore = true
        }
    }
}

Jeśli chcesz, aby moduł testowy był kierowany tylko na określone smaki lub typy kompilacji aplikacji, możesz użyć właściwości matchingFallbacks, aby kierować reklamy tylko na warianty, które chcesz przetestować. Zapobiega to też konieczności samodzielnego konfigurowania tych wariantów przez moduł testowy.