Zaawansowana konfiguracja testu

Testuj w Android Studio oraz Przetestuj z wiersza poleceń – wyjaśnij, jak ustawić i uruchomić podstawowe konfiguracje testowe. Gdy jednak Twoja aplikacja i jej są bardziej zaawansowane, może być konieczne dostosowanie testu konfiguracji. Zaawansowana konfiguracja testów może być potrzebna np. wtedy, gdy chcesz wykonać te czynności:

• Przeprowadzaj testy zinstruowane tylko w przypadku określonego wariantu kompilacji lub zastąp jego ustawieniach pliku manifestu.
• Zmień typ kompilacji, na którym przeprowadzane są testy, lub skonfiguruj Gradle .
• Wyodrębnianie testów zdemontowanych do osobnego modułu testów.
• Przeprowadź bardziej zaawansowane testy w ramach konfiguracji ciągłej integracji.

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

Tworzenie testu instrumentowanego dla wariantu kompilacji

Jeśli projekt obejmuje warianty kompilacji z parametrem unikalnych zbiorów źródłowych, warto uwzględnić testy instrumentowane, odpowiadającym zbiorom źródłowym. Pozwala to uporządkować kod testowy umożliwia uruchamianie tylko testów, które dotyczą danego wariantu kompilacji.

Aby połączyć testy zinstrumentowane z wariantem kompilacji, umieść je w ich własnym zbiór źródeł umieszczony na stronie src/androidTestVariantName

Testy instrumentowane w zbiorze źródłowym src/androidTest/ są udostępniane wszystkim wariantów kompilacji. Podczas tworzenia testowego pakietu APK dla aplikacji „MyFlavor” wersji Gradle łączy w sobie src/androidTest/ i src/androidTestMyFlavor/ zbiorów źródłowych.

Aby dodać zestaw źródeł testowych dla wariantu kompilacji w Android Studio, wykonaj te czynności 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 kliknij Nowy > Katalog.
3. Jako nazwę katalogu wpisz „androidTestNazwa wariantu”. Na przykład, jeśli masz wariant kompilacji o nazwie „MyFlavor”, użyj nazwy katalogu androidTestMyFlavor
4. Kliknij OK.
5. Kliknij prawym przyciskiem myszy nowy katalog i wybierz New (Nowy) > Katalog.
6. Wpisz „java” jako nazwę katalogu, a następnie kliknij OK.

Teraz możesz dodać testy do tego nowego zbioru źródeł, postępując zgodnie z instrukcje dodawania nowego testu. W oknie Choose Target Directory (Wybierz katalog docelowy) wybierz nowy zestaw źródłowy testu wariantu.

W tabeli poniżej znajdziesz przykładowe pliki testowe narzędzi znajdują się w zbiorach źródłowych, które odpowiadają zbiocjom źródłowym kodu aplikacji:

Tabela 1. Kod źródłowy aplikacji i odpowiadający mu kod źródłowy pliki testowe narzędzi

Tak jak w przypadku zbiorów źródeł aplikacji, kompilacja Gradle łączy się zastępuje pliki z różnych zbiorów źródłowych testu. W tym przypadku parametr AndroidExampleTest.java plik w zastąpieniach zestawu źródłowego androidTestMyFlavor wersję w zbiorze źródłowym androidTest. Dzieje się tak, ponieważ zbiór źródeł smaków produktu ma wyższy priorytet niż główny zbiór źródeł.

Jeśli w selektorze wariantów wybierzesz różne smaki, odpowiednie foldery androidTest są wyświetlane w widoku Androida, które pliki są używane:

Folder androidTestMyFlavor nie jest wyświetlany, gdy występuje inny wariant wybrano:

Sytuacja wygląda trochę inaczej w widoku Projekt, ale jest on taki sam. obowiązuje zasada:

Jeśli wybierzesz inny wariant, folder androidTestMyFlavor pozostanie bez zmian widoczna, ale nie jest wyświetlana jako aktywna:

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

Skonfiguruj ustawienia pliku manifestu instrumentacji

Testy instrumentalne są wbudowane w oddzielny plik APK z osobnym plikiem APK AndroidManifest.xml. Gdy Gradle skompiluje testowy plik APK, automatycznie generuje i konfiguruje plik AndroidManifest.xml z <instrumentation>. Jednym z powodów, dla których Gradle konfiguruje ten węzeł za Ciebie, jest zapewnienie, targetPackage określa prawidłową nazwę pakietu testowanej aplikacji.

Aby zmienić inne ustawienia tego węzła, utwórz plik manifestu w testowym zestawie źródeł lub skonfiguruj na poziomie modułu build.gradle plik, tak jak w tabeli ten przykładowy kod. Pełną listę opcji znajdziesz w BaseFlavor Dokumentacja API.

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"
}

Konfigurowanie opcji testu Gradle

Dzięki wtyczce Androida do obsługi Gradle możesz: określić opcje dla wszystkich lub tylko niektórych testów. W build.gradle na poziomie modułu, użyj funkcji testOptions. blok, aby określić opcje, które zmieniają sposób, w jaki Gradle uruchamia wszystkie testy:

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 test raportów. Domyślnie Gradle zapisuje raporty z testów w Katalog path_to_your_project/module_name /build/outputs/reports/. $rootDir ustawia względną ścieżkę w katalogu głównym bieżącego projektu.

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

Aby określić opcje tylko dla lokalnych testów jednostkowych, skonfiguruj parametr unitTests w obrębie 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 kod próbuje uzyskać dostęp do interfejsów API platformy Androida, chyba że przykładowe zależności Androida samodzielnie lub za pomocą platformy testowej, Mockito. Możesz jednak włączyć właściwość returnDefaultValues, aby przy dostępie do interfejsów API platformy test zwraca wartość null lub zero, niż na zrobienie wyjątku.

Blok all zawiera opcje umożliwiające kontrolowanie działania Gradle lokalnych testów jednostkowych. Listę wszystkich dostępnych opcji znajdziesz w artykule Dokumentacja Gradle

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

Możesz też sprawdzić nazwę zadania, aby zastosować opcje tylko do wybranych testów określić. We przykładowym fragmencie kodu właściwość debug ma wartość true, ale tylko w przypadku zadania testDebugUnitTest.

Używaj osobnych modułów do testów instrumentowanych

Jeśli chcesz mieć specjalny moduł do testów instrumentowanych, w celu wyodrębnienia reszty kodu z testów, utwórz oddzielny moduł testowy i skonfigurować jego strukturę podobnie do modułu biblioteki.

Aby utworzyć moduł testowy, wykonaj te czynności:

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

Po utworzeniu modułu testowego możesz umieścić kod testu w sekcji ustawiono główny element źródła lub wariant źródła (np. src/main/java lub src/variant/java). Jeśli moduł aplikacji określa różnych smaków, możesz odtworzyć je w module testowym. Korzystanie z zależności uwzględniającego wariant , moduł testowy próbuje sprawdzić rodzaj dopasowania w module docelowym.

Domyślnie moduły testowe zawierają i testują tylko wariant do debugowania. Pamiętaj jednak: możesz tworzyć nowe typy kompilacji pasujące do testowanego projektu aplikacji. Aby w module testowym przetestujesz inny typ kompilacji, a nie ten do debugowania, użyj VariantFilter, aby wyłączyć wariant 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, by moduł testowy był kierowany tylko na niektóre rodzaje lub typy kompilacji aplikacji, możesz użyć funkcji matchingFallbacks aby kierować reklamy tylko na warianty, które chcesz przetestować. Zapobiega to także aby nie trzeba było samodzielnie konfigurować tych wariantów.