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