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

Pfad zur App-Klasse	Pfad zur Testklasse für übereinstimmende Instrumentierungstests
src/main/java/Example.java	src/androidTest/java/AndroidExampleTest.java
src/myFlavor/java/Example.java	src/androidTestMyFlavor/java/AndroidExampleTest.java

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 type="x-smartling-placeholder">

</ph>

Abbildung 1: MyFlavor Variante ausgewählt; die In der Android-Ansicht wird der Ordner androidTestMyFlavor angezeigt.

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

<ph type="x-smartling-placeholder">

</ph>

Abbildung 2: OtherFlavor Variante ausgewählt; die Der Ordner androidTestMyFlavor wird in der Android-Ansicht nicht angezeigt.

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

<ph type="x-smartling-placeholder">

</ph>

Abbildung 3: MyFlavor Variante ausgewählt; die Der Ordner androidTestMyFlavor ist in der Ansicht Projekt aktiv.

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

<ph type="x-smartling-placeholder">

</ph>

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

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

Cool

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 der Tests festlegen. Im Datei build.gradle auf Modulebene die Methode testOptions , um Optionen anzugeben, die ändern, wie Gradle alle deine Tests ausführt:

Cool

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 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.

Cool

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 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:

Cool

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 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.