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:
- Klicken Sie im Fenster Projekt auf das Menü und wählen Sie in der Ansicht Projekt
- Klicken Sie im entsprechenden Modulordner mit der rechten Maustaste auf den Ordner src. Klicken Sie auf Neu > Verzeichnis.
- Geben Sie als Verzeichnisnamen „androidTestVariantName“ ein. Wenn beispielsweise
haben Sie eine Build-Variante
namens „MyFlavor“, Verwenden Sie den Verzeichnisnamen
androidTestMyFlavor
- Klicken Sie auf OK.
- Klicken Sie mit der rechten Maustaste auf das neue Verzeichnis und wählen Sie New > Verzeichnis.
- 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:
![MyFlavor-Variante ausgewählt und der Ordner „androidTestMyFlavor“ wird angezeigt
in der Android-Ansicht](https://developer.android.com/static/studio/images/test/test-myflavor-android-test-android-view.png?authuser=0000&hl=de)
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:
![Die Variante „OtherFlavor“ wurde ausgewählt und der Ordner „androidTestMyFlavor“ ist nicht ausgewählt
Wird in der Android-Ansicht angezeigt](https://developer.android.com/static/studio/images/test/test-otherflavor-android-test-android-view.png?authuser=0000&hl=de)
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">![MyFlavor-Variante ausgewählt und der Ordner „androidTestMyFlavor“ ist aktiv
in der Projektansicht](https://developer.android.com/static/studio/images/test/test-myflavor-android-test-project-view.png?authuser=0000&hl=de)
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:
![Die Variante „OtherFlavor“ wurde ausgewählt und der Ordner „androidTestMyFlavor“ ist nicht ausgewählt
in der Projektansicht aktiv](https://developer.android.com/static/studio/images/test/test-otherflavor-android-test-project-view.png?authuser=0000&hl=de)
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:
- Erstellen Sie ein Bibliotheksmodul.
- Wenden Sie in der Datei
build.gradle
auf Modulebenecom.android.test
an. Plug-in anstelle voncom.android.library
. - 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.