Zaawansowana konfiguracja testu

Testowanie w Android Studio i Testowanie z poziomu wiersza poleceń wyjaśniają, jak skonfigurować i uruchomić podstawowe konfiguracje testów. Gdy jednak Twoja aplikacja i jej wymagania testowe staną się bardziej zaawansowane, może być konieczne dalsze dostosowanie konfiguracji testów. Zaawansowana konfiguracja testów może być potrzebna np. w tych przypadkach:

• Uruchamianie testów instrumentacyjnych tylko w przypadku określonego wariantu kompilacji lub zastępowanie jego ustawień manifestu.
• Zmienianie rodzaju kompilacji, w przypadku którego uruchamiane są testy, lub konfigurowanie jego opcji Gradle.
• Wyodrębnianie testów instrumentacyjnych do osobnego modułu testowego.
• Przeprowadzanie bardziej zaawansowanych testów w ramach konfiguracji ciągłej integracji.

Na tej stronie opisujemy różne sposoby konfigurowania testów, gdy ustawienia domyślne nie spełniają Twoich potrzeb.

Tworzenie testu instrumentacyjnego dla wariantu kompilacji

Jeśli Twój projekt zawiera warianty kompilacji z unikalnymi zestawami źródeł, możesz uwzględnić testy instrumentacyjne, które odpowiadają tym zestawom źródeł. Dzięki temu kod testowy jest uporządkowany i możesz uruchamiać tylko testy, które dotyczą danego wariantu kompilacji.

Aby połączyć testy instrumentacyjne z wariantem kompilacji, umieść je w osobnym zestawie źródeł znajdującym się w src/androidTestVariantName.

Testy instrumentacyjne w zestawie źródeł src/androidTest/ są współdzielone przez wszystkie warianty kompilacji. Podczas tworzenia testowego pliku APK dla wariantu „MyFlavor” Twojej aplikacji Gradle łączy zestawy źródeł src/androidTest/ i src/androidTestMyFlavor/.

Aby dodać zbiór źródeł testowych dla wariantu kompilacji w Android Studio, wykonaj następujące kroki:

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

Teraz możesz dodać testy do tego nowego zbioru źródeł, wykonując czynności opisane w artykule Dodawanie nowego testu. Gdy pojawi się okno Wybierz katalog docelowy, wybierz nowy zbiór źródeł testowych wariantu.

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

Tabela 1. Kod źródłowy aplikacji i odpowiadające mu pliki testów z instrumentacją

Podobnie jak w przypadku zestawów źródeł aplikacji, kompilacja Gradle scala i zastępuje pliki z różnych zestawów źródeł testowych. W tym przypadku plik AndroidExampleTest.kt w zestawie źródeł androidTestMyFlavor zastępuje wersję w zestawie źródeł androidTest. Dzieje się tak, ponieważ zestaw źródeł wariantu produktu ma priorytet przed głównym zestawem źródeł.

Gdy w selektorze wariantów kompilacji wybierzesz różne warianty, w widoku Android zostaną wyświetlone odpowiednie foldery androidTest, aby pokazać foldery, które są używane:

Gdy wybierzesz inny wariant, folder androidTestMyFlavor nie będzie widoczny:

Jeśli używasz widoku Projekt , wygląda to nieco inaczej, ale obowiązuje ta sama zasada:

Gdy wybierzesz inny wariant, folder androidTestMyFlavor będzie nadal widoczny, ale nie będzie oznaczony jako aktywny:

Więcej informacji o scalaniu zestawów źródeł znajdziesz w artykule Zestawy źródeł.

Konfigurowanie ustawień manifestu instrumentacji

Testy instrumentacyjne są wbudowane w osobny plik APK z własnym plikiem AndroidManifest.xml. Gdy Gradle tworzy testowy plik APK, automatycznie generuje plik AndroidManifest.xml i konfiguruje go za pomocą węzła <instrumentation>. Jednym z powodów, dla których Gradle konfiguruje ten węzeł, jest upewnienie się, że właściwość targetPackage określa prawidłową nazwę pakietu testowanej aplikacji.

Aby zmienić inne ustawienia tego węzła, utwórz kolejny plik manifestu w zestawie źródeł testowych lub skonfiguruj plik build.gradle na poziomie modułu, jak pokazano w tym przykładowym kodzie. Pełną listę opcji znajdziesz w BaseFlavor dokumentacji 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
    }
}

Każdy skonfigurowany wariant produktu może zastępować właściwości w bloku defaultConfig {}. Więcej informacji znajdziesz w artykule Konfigurowanie wariantów produktu.

Właściwości w tym fragmencie kodu to:

Zmienianie rodzaju kompilacji testowej

Domyślnie wszystkie testy z instrumentacją są uruchamiane w przypadku rodzaju kompilacji debug. Możesz to zmienić na inny rodzaj kompilacji, używając właściwości testBuildType w pliku build.gradle na poziomie modułu. Jeśli na przykład chcesz uruchamiać testy w przypadku rodzaju kompilacji staging, edytuj plik tak jak w tym fragmencie kodu:

android {
    ...
    testBuildType = "staging"
}

android {
    ...
    testBuildType "staging"
}

Konfigurowanie opcji testów Gradle

Wtyczka Android Gradle umożliwia określanie niektórych opcji dla wszystkich lub tylko niektórych testów. W pliku na poziomie modułu użyj bloku, aby określić opcje, które zmieniają sposób uruchamiania wszystkich testów przez Gradle:build.gradletestOptions

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

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

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

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

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

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

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

Blok all zawiera opcje sterowania sposobem wykonywania lokalnych testów jednostkowych przez Gradle. Listę wszystkich opcji, które możesz określić, znajdziesz w dokumentacji referencyjnej Gradle.

Właściwość jvmArgs ustawia argumenty JVM dla testowych maszyn 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 do testów instrumentacyjnych

Jeśli chcesz mieć osobny moduł do testów instrumentacyjnych, aby odizolować resztę kodu od testów, utwórz osobny moduł testowy i skonfiguruj jego kompilację podobnie jak w przypadku modułu biblioteki.

Aby utworzyć moduł testowy:

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ódeł lub w zestawie źródeł wariantu (np. src/main/kotlin+java lub src/variant/kotlin+java). Jeśli moduł aplikacji definiuje wiele wariantów produktu, możesz je odtworzyć w module testowym . Dzięki zarządzaniu zależnościami uwzględniającemu warianty, moduł testowy próbuje przetestować pasujący wariant w module docelowym.

Domyślnie moduły testowe zawierają i testują tylko wariant debugowania. Możesz jednak utworzyć nowe typy kompilacji, które będą pasować do testowanego projektu aplikacji. Aby moduł testowy testował inny rodzaj kompilacji niż debugowanie, użyj VariantFilter, aby wyłączyć wariant debugowania w projekcie testowym, jak pokazano poniżej:

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

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

Jeśli chcesz, aby moduł testowy był kierowany tylko na określone warianty lub typy kompilacji aplikacji, możesz użyć właściwości matchingFallbacks, aby kierować reklamy tylko na warianty, które chcesz testować. Dzięki temu moduł testowy nie musi samodzielnie konfigurować tych wariantów.