Erweiterte Testeinrichtung

In Android Studio testen und Über die Befehlszeile testen und Erklären, wie grundlegende Testkonfigurationen einrichten und ausführen. Wenn Ihre App und ihre fortgeschritteneren Testanforderungen, müssen Sie den Test möglicherweise weitere Konfigurationen vornehmen. Beispielsweise kann eine erweiterte Testeinrichtung erforderlich sein, wenn sollten Sie Folgendes tun:

• Instrumentierte Tests nur für eine bestimmte Build-Variante ausführen oder deren Manifest-Einstellungen.
• Build-Typ ändern, für den die Tests ausgeführt werden, oder Gradle konfigurieren Optionen.
• Extrahieren Sie Ihre instrumentierten Tests in ein eigenes Testmodul.
• Im Rahmen der Einrichtung der kontinuierlichen Integration können Sie erweiterte Tests durchführen.

Auf dieser Seite werden verschiedene Möglichkeiten zum Konfigurieren von Tests beschrieben, wenn die Standardeinstellung nicht Ihren Anforderungen entsprechen.

Instrumentierten Test für eine Build-Variante erstellen

Wenn Ihr Projekt Build-Varianten mit eindeutige Quellsätze enthalten, können Sie instrumentierte Tests die diesen Quellsätzen entsprechen. So bleibt Ihr Testcode organisiert und können Sie 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 separaten Quellsatz, gespeichert unter src/androidTestVariantName

Instrumentierte Tests im Quellsatz src/androidTest/ werden von allen gemeinsam genutzt zu erstellen. Beim Erstellen eines Test-APKs für "MyFlavor" Variante Ihrer kombiniert Gradle die src/androidTest/ und die src/androidTestMyFlavor/ Quellsätzen.

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

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

Jetzt können Sie diesem neuen Quellsatz Tests hinzufügen, indem Sie der Schritte zum Hinzufügen eines neuen Tests. Wählen Sie im Dialogfeld Zielverzeichnis auswählen das neue Quellsatz des Variantentests.

Die folgende Tabelle zeigt ein Beispiel dafür, wie Instrumentierungstestdateien befinden sich in Quellsätzen, die den Codequellsätzen der App entsprechen:

Tabelle 1 Quellcode der App und entsprechende Dateien für Instrumentierungstests

Genau wie bei Ihren Anwendungsquellsätzen führt der Gradle-Build überschreibt Dateien aus verschiedenen Testquellsätzen. In diesem Fall Datei „AndroidExampleTest.java“ in der Quellgruppe „androidTestMyFlavor“ überschreibt Die Version im Quellsatz androidTest. Das liegt daran, hat die Geschmacksquelle des Produkts Vorrang vor der Hauptquellengruppe.

Wenn Sie in der Auswahl für Build-Varianten verschiedene Geschmacksrichtungen auswählen, werden in der Android-Ansicht die entsprechenden androidTest Ordner angezeigt, die verwendeten Ordner anzeigen:

</ph>

Der Ordner „androidTestMyFlavor“ wird nicht angezeigt, wenn eine andere Variante Ausgewählt:

</ph>

In der Projektansicht sieht das Ergebnis etwas anders aus. gilt:

</ph>

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

</ph>

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

Manifesteinstellungen für die Instrumentierung konfigurieren

Instrumentierte Tests sind in einem separaten APK mit einer eigenen AndroidManifest.xml-Datei. Wenn Gradle Ihr Test-APK erstellt, generiert automatisch die Datei AndroidManifest.xml und konfiguriert sie mit dem <instrumentation>-Knoten. Gradle konfiguriert diesen Knoten unter anderem, um sicherzustellen, targetPackage gibt den richtigen Paketnamen der zu testenden App an.

Wenn Sie andere Einstellungen für diesen Knoten ändern möchten, müssen Sie entweder einen weiteren erstellen Manifestdatei im Testquellsatz oder konfigurieren Sie die Modulebene build.gradle-Datei, wie in das folgende Codebeispiel. Die vollständige Liste der Optionen findest du in der BaseFlavor API-Referenz

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

Gradle-Testoptionen konfigurieren

Mit dem Android-Gradle-Plug-in können Sie bestimmte Optionen für alle oder nur für einige der Tests festlegen. Im Datei build.gradle auf Modulebene die Methode testOptions , um Optionen anzugeben, die ändern, wie Gradle alle deine Tests ausführt:

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

Durch das Attribut reportDir wird das Verzeichnis geändert, in dem Gradle den Test speichert. Berichte. Standardmäßig speichert Gradle Testberichte in der path_to_your_project/module_name /build/outputs/reports/-Verzeichnis. $rootDir legt den relativen Pfad fest. zum Stammverzeichnis des aktuellen Projekts.

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

Wenn Sie Optionen nur für lokale Einheitentests angeben möchten, konfigurieren Sie die Methode unitTests in 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")
                }
                ...
            }
        }
    }
}

Standardmäßig wird bei Tests lokaler Einheiten jedes Mal eine Ausnahme ausgelöst, wenn der Code beim Testen versuchen, auf Android-Plattform-APIs zuzugreifen, es sei denn, Sie Android-Abhängigkeiten simulieren oder mit einem Testframework wie Mockito. Sie können jedoch das Attribut returnDefaultValues aktivieren, damit gibt der Test beim Zugriff auf Plattform-APIs entweder Null oder Null zurück, anstatt als das Auslösen einer Ausnahme.

Der all-Block enthält Optionen zur Steuerung der Ausführung von Gradle. lokale Unittests. Eine Liste aller verfügbaren Optionen finden Sie unter Referenzdokumentation von Gradle

Mit dem Attribut jvmArgs werden JVM-Argumente für die Test-JVM festgelegt.

Sie können auch den Aufgabennamen prüfen, um Optionen nur auf die Tests anzuwenden, angeben. 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 spezielles Modul für instrumentierte Tests benötigen, Erstellen Sie ein separates Testmodul und konfigurieren seinen Build ähnlich dem eines Bibliotheksmoduls.

So erstellen Sie ein Testmodul:

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

Nachdem Sie Ihr Testmodul erstellt haben, können Sie Ihren Testcode in das Haupt- oder Variantenquellensatz (z. B. src/main/java oder src/variant/java). Wenn in Ihrem App-Modul verschiedenen Geschmacksrichtungen, können Sie diese in Ihrem Testmodul nachbilden. Variantensensitive Abhängigkeit verwenden Verwaltung versucht das Testmodul, den passenden Flavor im Zielmodul zu testen.

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

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

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

Wenn ein Testmodul nur auf bestimmte Geschmacksrichtungen oder Build-Typen einer App kannst du die matchingFallbacks verwenden , um eine Ausrichtung nur auf die zu testenden Varianten vorzunehmen. Außerdem wird dadurch verhindert, Testmodul diese Varianten nicht für sich selbst konfigurieren zu müssen.