Erweiterte Testeinrichtung

Unter In Android Studio testen und Über die Befehlszeile testen wird erläutert, wie grundlegende Testkonfigurationen eingerichtet und ausgeführt werden. Wenn Ihre Anwendung und ihre Testanforderungen jedoch anspruchsvoller werden, müssen Sie Ihre Testkonfigurationen möglicherweise weiter anpassen. Eine erweiterte Testeinrichtung ist beispielsweise erforderlich, wenn Sie Folgendes tun möchten:

• Instrumentierte Tests nur für eine bestimmte Build-Variante ausführen oder die zugehörigen Manifesteinstellungen überschreiben
• Ändern Sie den Build-Typ, für den Ihre Tests ausgeführt werden, oder konfigurieren Sie die zugehörigen Gradle-Optionen.
• Extrahieren Sie Ihre instrumentierten Tests in ein eigenes Testmodul.
• Im Rahmen der Einrichtung von Continuous Integration können Sie erweiterte Tests durchführen.

Auf dieser Seite werden verschiedene Möglichkeiten zur Konfiguration von Tests beschrieben, wenn die Standardeinstellungen Ihren Anforderungen nicht entsprechen.

Instrumentierten Test für eine Build-Variante erstellen

Wenn Ihr Projekt Build-Varianten mit eindeutigen Quellsätzen enthält, können Sie auch instrumentierte Tests einbeziehen, die diesen Quellsätzen entsprechen. So bleibt der Testcode organisiert und Sie können nur die Tests ausführen, die für eine bestimmte Build-Variante gelten.

Wenn Sie instrumentierte Tests mit einer Build-Variante verknüpfen möchten, platzieren Sie sie in einem eigenen Quellsatz unter src/androidTestVariantName.

Instrumentierte Tests im Quellsatz src/androidTest/ werden von allen Build-Varianten gemeinsam verwendet. Beim Erstellen eines Test-APKs für die „MyFlavor“-Variante Ihrer App kombiniert Gradle die Quellsätze src/androidTest/ und src/androidTestMyFlavor/.

So fügen Sie in Android Studio eine Testquellengruppe für Ihre Build-Variante hinzu:

1. Klicken Sie im Fenster Projekt auf das Menü und wählen Sie die Ansicht Projekt aus.
2. Klicken Sie im entsprechenden Modulordner mit der rechten Maustaste auf den Ordner src und dann auf New > Directory.
3. Geben Sie als Verzeichnisnamen "androidTestVariantName" ein. Wenn Sie beispielsweise eine Build-Variante namens „MyFlavor“ haben, verwenden Sie den Verzeichnisnamen androidTestMyFlavor.
4. Klicke auf OK.
5. Klicken Sie mit der rechten Maustaste auf das neue Verzeichnis und wählen Sie Neu > Verzeichnis aus.
6. Geben Sie „java“ als Verzeichnisnamen ein und klicken Sie auf OK.

Jetzt können Sie dieser neuen Quellgruppe Tests hinzufügen. Folgen Sie dazu den Schritten zum Hinzufügen eines neuen Tests. Wählen Sie im Dialogfeld Zielverzeichnis auswählen die neue Variantentestquellengruppe aus.

Die folgende Tabelle zeigt ein Beispiel dafür, wie Instrumentierungstestdateien in Quellsätzen gespeichert werden können, die den Codequellsätzen der Anwendung entsprechen:

Tabelle 1 den App-Quellcode und entsprechende Instrumentierungstestdateien

Pfad zur App-Klasse	Pfad zur übereinstimmenden Instrumentierungstestklasse
src/main/java/Example.java	src/androidTest/java/AndroidExampleTest.java
src/myFlavor/java/Example.java	src/androidTestMyFlavor/java/AndroidExampleTest.java

Genau wie bei Ihren App-Quellsätzen werden mit dem Gradle-Build Dateien aus verschiedenen Testquellsätzen zusammengeführt und überschrieben. In diesem Fall überschreibt die Datei AndroidExampleTest.java im Quellsatz androidTestMyFlavor die Version im Quellsatz androidTest. Dies liegt daran, dass der Quellsatz für Produktvarianten Vorrang vor dem Quellquellsatz hat.

Wenn Sie in der Build-Variantenauswahl verschiedene Varianten auswählen, werden in der Ansicht Android die entsprechenden androidTest-Ordner mit den verwendeten Ordnern angezeigt:

Abbildung 1: MyFlavor Variante ausgewählt. Der Ordner androidTestMyFlavor wird in der Ansicht Android angezeigt.

Der Ordner androidTestMyFlavor wird nicht angezeigt, wenn eine andere Variante ausgewählt ist:

Abbildung 2: OtherFlavor Variante ausgewählt. Der Ordner „androidTestMyFlavor“ wird in der Ansicht Android nicht angezeigt.

Wenn Sie die Ansicht Projekt verwenden, sieht dies etwas anders aus, das Prinzip gilt jedoch:

Abbildung 3: MyFlavor Variante ausgewählt. Der Ordner androidTestMyFlavor ist in der Projektansicht aktiv.

Wenn eine andere Variante ausgewählt wird, ist der Ordner androidTestMyFlavor weiterhin sichtbar, wird aber nicht als aktiv angezeigt:

Abbildung 4: OtherFlavor Variante ausgewählt. Der Ordner androidTestMyFlavor ist in der Projektansicht nicht aktiv.

Weitere Informationen zum Zusammenführen von Quellsätzen finden Sie unter Quellsätze.

Einstellungen für das Instrumentierungsmanifest konfigurieren

Instrumentierte Tests werden in ein separates APK mit eigener AndroidManifest.xml-Datei eingebunden. Wenn Gradle dein Test-APK erstellt, wird automatisch die Datei AndroidManifest.xml generiert und mit dem Knoten <instrumentation> konfiguriert. Gradle konfiguriert diesen Knoten unter anderem, damit im Attribut targetPackage der richtige Paketname der zu testenden App angegeben ist.

Wenn Sie andere Einstellungen für diesen Knoten ändern möchten, erstellen Sie entweder eine weitere Manifestdatei im Testquellsatz oder konfigurieren Sie die Datei build.gradle auf Modulebene, wie im folgenden Codebeispiel gezeigt. Die vollständige Liste der Optionen finden Sie in der API-Referenz BaseFlavor.

Groovig

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

Kotlin

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:

Setting	Description
testApplicationId	Specifies the application ID for the test APK.
testInstrumentationRunner	Specifies the fully qualified class name of the test instrumentation runner.
testHandleProfiling	If set to true, enables the instrumentation class to start and stop profiling. If set to false, profiling occurs the entire time the instrumentation class is running.
testFunctionalTest	If set to true, indicates that the Android system should run the instrumentation class as a functional test. The default value is false.

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:

Groovy

android {
    ...
    testBuildType "staging"
}

Kotlin

android {
    ...
    testBuildType = "staging"
}

Gradle-Testoptionen konfigurieren

Mit dem Android-Gradle-Plug-in können Sie bestimmte Optionen für alle oder nur für einige Ihrer Tests angeben. Verwenden Sie in der Datei build.gradle auf Modulebene den Block testOptions, um Optionen anzugeben, die ändern, wie Gradle alle Ihre Tests ausführt:

Groovig

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

Kotlin

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

Durch das Attribut reportDir wird das Verzeichnis geändert, in dem Gradle Testberichte speichert. Gradle speichert Testberichte standardmäßig im Verzeichnis path_to_your_project/module_name /build/outputs/reports/. $rootDir legt den Pfad relativ zum Stammverzeichnis des aktuellen Projekts fest.

Durch das Attribut resultsDir wird das Verzeichnis geändert, in dem Gradle die Testergebnisse speichert. Standardmäßig speichert Gradle Testergebnisse im Verzeichnis path_to_your_project/module_name /build/outputs/test-results/. $rootDir legt den Pfad relativ zum Stammverzeichnis des aktuellen Projekts fest.

Wenn Sie Optionen nur für lokale Einheitentests angeben möchten, konfigurieren Sie den Block unitTests in testOptions.

Groovig

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

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

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

Kotlin

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

Standardmäßig wird bei lokalen Einheitentests jedes Mal eine Ausnahme ausgegeben, wenn der getestete Code versucht, auf Android-Plattform-APIs zuzugreifen, es sei denn, Sie mockieren Android-Abhängigkeiten selbst oder mit einem Test-Framework wie Mockito. Sie können jedoch das Attribut returnDefaultValues aktivieren, sodass der Test beim Zugriff auf Plattform-APIs entweder null oder null zurückgibt, anstatt eine Ausnahme auszulösen.

Der all-Block enthält Optionen, mit denen Sie steuern können, wie Gradle lokale Einheitentests ausführt. Eine Liste aller verfügbaren Optionen finden Sie in der Referenzdokumentation zu Gradle.

Mit der Eigenschaft jvmArgs werden JVM-Argumente für die Test-JVM(s) festgelegt.

Sie können auch den Aufgabennamen prüfen, um Optionen nur auf die von Ihnen angegebenen Tests anzuwenden. Im Beispiel-Snippet ist das Attribut debug auf true festgelegt, aber nur für die Aufgabe testDebugUnitTest.

Separate Testmodule für instrumentierte Tests verwenden

Wenn Sie ein dediziertes Modul für instrumentierte Tests verwenden möchten, um den Rest des Codes von Ihren Tests zu isolieren, erstellen Sie ein separates Testmodul und konfigurieren Sie seinen Build ähnlich wie ein Bibliotheksmodul.

So erstellen Sie ein Testmodul:

1. Ein Bibliotheksmodul erstellen
2. Wenden Sie in der Datei build.gradle auf Modulebene das Plug-in com.android.test anstelle von com.android.library an.
3. Klicken Sie auf Projekt synchronisieren .

Nachdem Sie das Testmodul erstellt haben, können Sie Ihren Testcode in den Haupt- oder Variantenquellsatz einfügen (z. B. src/main/java oder src/variant/java). Wenn Ihr App-Modul mehrere Produktvarianten definiert, können Sie diese in Ihrem Testmodul neu erstellen. Mithilfe der variantenbasierten Abhängigkeitsverwaltung versucht das Testmodul, die passende Variante im Zielmodul zu testen.

Standardmäßig enthalten und testen Testmodule nur eine Variante zur Fehlerbehebung. Sie können jedoch neue Build-Typen erstellen, die dem getesteten App-Projekt entsprechen. Wenn das Testmodul einen anderen Build-Typ als den Debug-Typ testen soll, verwenden Sie VariantFilter, um die Debug-Variante im Testprojekt zu deaktivieren:

Groovig

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

Kotlin

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

Wenn ein Testmodul nur auf bestimmte Varianten oder Build-Typen einer Anwendung ausgerichtet sein soll, können Sie mit dem Attribut matchingFallbacks nur die Varianten auswählen, die Sie testen möchten. Außerdem muss das Testmodul diese Varianten so nicht selbst konfigurieren.