Artykuł Testowanie w Android Studio i Testowanie z poziomu wiersza poleceń wyjaśniają, jak przygotowywać i uruchamiać podstawowe konfiguracje testowe. Jednak gdy Twoja aplikacja i jej wymagania testowe staną się bardziej zaawansowane, konieczne może być dalsze dostosowanie konfiguracji testów. Zaawansowana konfiguracja testów może być potrzebna np. wtedy, gdy chcesz:
- Przeprowadzaj testy instrumentalne tylko dla określonego wariantu kompilacji lub zastąp ustawienia w jego pliku manifestu.
- Zmień typ kompilacji, na którym są wykonywane testy, lub skonfiguruj jego opcje Gradle.
- Wyodrębnij testy z instrumentowane do osobnego modułu testowego.
- Przeprowadź bardziej zaawansowane testy w ramach konfiguracji ciągłej integracji.
Na tej stronie opisujemy różne sposoby konfigurowania testów, gdy domyślne ustawienia nie odpowiadają Twoim potrzebom.
Tworzenie testu instrumentowanego dla wariantu kompilacji
Jeśli Twój projekt obejmuje warianty kompilacji z unikalnymi zbiorami źródłowymi, możesz uwzględnić testy instrumentowane, które odpowiadają tym zbiorom źródłowym. Pozwala to zachować porządek w kodzie testowym i umożliwia uruchamianie tylko tych testów, które dotyczą danego wariantu kompilacji.
Aby połączyć testy instrumentowane z wariantem kompilacji, umieść je w osobnym zbiorze źródłowym w src/androidTestVariantName
.
Testy z instrumentów w zbiorze źródłowym src/androidTest/
są używane przez wszystkie warianty kompilacji. Podczas tworzenia testowego pakietu APK dla wariantu aplikacji „MyFlavor” Gradle łączy zestawy źródłowe src/androidTest/
i src/androidTestMyFlavor/
.
Aby dodać zestaw źródeł testowych do wariantu kompilacji w Android Studio, wykonaj te czynności:
- W oknie Projekt kliknij menu i wybierz widok Projekt.
- W odpowiednim folderze modułu kliknij prawym przyciskiem myszy folder src, a następnie Nowy > Katalog.
- Jako nazwę katalogu wpisz „androidTestVariantName”. Jeśli na przykład masz wariant kompilacji o nazwie „MójSmak”, użyj nazwy katalogu
androidTestMyFlavor
. - Kliknij OK.
- Kliknij nowy katalog prawym przyciskiem myszy i wybierz Nowy > Katalog.
- Jako nazwę katalogu wpisz „java” i kliknij OK.
Możesz teraz dodawać testy do nowego zbioru źródłowego, wykonując te czynności. Gdy dojdziesz do okna Wybierz katalog docelowy, wybierz nowy testowy zbiór źródeł wariantów.
W tabeli poniżej znajdziesz przykład tego, jak pliki testowe z instrumentacją mogą się znajdować w zbiorach źródłowych odpowiadających zbiorom źródłowym kodu aplikacji:
Ścieżka klasy aplikacji | Ścieżka do pasującej klasy testowej z instrumentacją |
---|---|
src/main/java/Example.java
|
src/androidTest/java/AndroidExampleTest.java
|
src/myFlavor/java/Example.java
|
src/androidTestMyFlavor/java/AndroidExampleTest.java
|
Tak jak w przypadku zbiorów źródłowych aplikacji, kompilacja Gradle scala i zastępuje pliki z różnych testowych zbiorów źródłowych. W tym przypadku plik AndroidExampleTest.java
w zbiorze źródłowym androidTestMyFlavor
zastępuje wersję w zbiorze źródłowym androidTest
. Dzieje się tak, ponieważ zestaw źródeł smaków produktu ma wyższy priorytet niż główny zestaw źródłowy.
Jeśli w selektorze wariantów kompilacji wybierzesz różne smaki, w widoku Android wyświetlą się odpowiednie foldery androidTest
, gdzie będą widoczne używane foldery:
Folder androidTestMyFlavor
nie wyświetla się, gdy wybrano inną wersję:
Wygląda to nieco inaczej w widoku Projekt, ale obowiązuje ta sama zasada:
Po wybraniu innej wersji folder androidTestMyFlavor
pozostaje widoczny, ale nie jest widoczny jako aktywny:
Więcej informacji o scalaniu zbiorów źródłowych znajdziesz w sekcji Zbiory źródłowe.
Skonfiguruj ustawienia pliku manifestu narzędzi
Testy z instrumentów są wbudowane w oddzielny plik APK z własnym plikiem AndroidManifest.xml
. Gdy Gradle skompiluje testowy pakiet APK, automatycznie generuje plik AndroidManifest.xml
i konfiguruje go w węźle <instrumentation>
.
Jednym z powodów, dla których Gradle konfiguruje ten węzeł za Ciebie, jest sprawdzenie, czy właściwość targetPackage
określa prawidłową nazwę pakietu testowanej aplikacji.
Aby zmienić inne ustawienia dla tego węzła, utwórz kolejny plik manifestu w testowym zestawie źródłowym lub skonfiguruj plik build.gradle
na poziomie modułu, jak pokazano w poniższym przykładowym kodzie. Pełną listę opcji znajdziesz w dokumentacji interfejsu API BaseFlavor
.
Odlotowy
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" }
Skonfiguruj opcje testu Gradle
Wtyczka Androida do obsługi Gradle umożliwia określenie opcji we wszystkich lub tylko w przypadku niektórych testów. W pliku build.gradle
na poziomie modułu użyj bloku testOptions
, aby określić opcje, które zmieniają sposób uruchamiania wszystkich testów przez Gradle:
Odlotowy
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" } }
Właściwość reportDir
zmienia katalog, w którym Gradle zapisuje raporty testowe. Domyślnie Gradle zapisuje raporty testowe w katalogu path_to_your_project/module_name
/build/outputs/reports/
. $rootDir
określa ścieżkę względną do katalogu głównego bieżącego projektu.
Właściwość resultsDir
zmienia katalog, w którym Gradle zapisuje wyniki testów. Domyślnie Gradle zapisuje wyniki testu w katalogu path_to_your_project/module_name
/build/outputs/test-results/
. $rootDir
określa ścieżkę względną do katalogu głównego bieżącego projektu.
Aby określić opcje tylko dla testów jednostkowych lokalnych, skonfiguruj blok unitTests
w testOptions
.
Odlotowy
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") } ... } } } }
Domyślnie testy jednostek lokalnych zgłaszają wyjątek za każdym razem, gdy testowany kod próbuje uzyskać dostęp do interfejsów API platformy Androida, chyba że imitujesz zależności Androida samodzielnie lub za pomocą platformy testowej takiej jak Mockito. Możesz jednak włączyć właściwość returnDefaultValues
, tak aby podczas uzyskiwania dostępu do interfejsów API platformy test zwracał wartość null lub 0, zamiast zgłaszać wyjątek.
Blok all
zawiera opcje umożliwiające kontrolowanie sposobu wykonywania przez Gradle testów jednostek lokalnych. Listę wszystkich opcji, które można określić, znajdziesz w dokumentacji referencyjnej Gradle.
Właściwość jvmArgs
ustawia argumenty JVM dla testowych JVM.
Możesz też sprawdzić nazwę zadania, aby zastosować opcje tylko do określonych testów. W przykładowym fragmencie kodu właściwość debug
jest ustawiona na true
, ale tylko w przypadku zadania testDebugUnitTest
.
Używanie osobnych modułów testowych na potrzeby testów z instrumentacją
Jeśli chcesz mieć specjalny moduł na potrzeby testów z instrumentacją, aby odizolować od testów pozostałe fragmenty kodu, utwórz osobny moduł testowy i skonfiguruj jego kompilację podobnie do modułu biblioteki.
Aby utworzyć moduł testowy, wykonaj następujące czynności:
- Utwórz moduł biblioteki.
- W pliku
build.gradle
na poziomie modułu zastosuj wtyczkęcom.android.test
zamiastcom.android.library
. - Kliknij Synchronizuj projekt .
Po utworzeniu modułu testowego możesz umieścić kod testowy w głównym zestawie źródłowym lub w zestawie źródłowym (np. src/main/java
lub src/variant/java
). Jeśli moduł aplikacji definiuje wiele smaków produktów, możesz odtworzyć te smaki w module testowym.
Za pomocą zarządzania zależnościami z uwzględnieniem wariantów moduł testowy próbuje przetestować pasujący rodzaj w module docelowym.
Domyślnie moduły testowe zawierają i testują tylko wariant do debugowania. Możesz jednak tworzyć nowe typy kompilacji pasujące do testowanego projektu aplikacji. Aby ustawić w module testowym inny typ kompilacji, a nie tę, użyj funkcji VariantFilter
do wyłączenia wariantu debugowania w projekcie testowym:
Odlotowy
android { variantFilter { variant -> if (variant.buildType.name.equals('debug')) { variant.setIgnore(true); } } }
Kotlin
android { variantFilter { if (buildType.name == "debug") { ignore = true } } }
Jeśli chcesz, aby moduł testowy był kierowany tylko na określone smaki lub typy kompilacji aplikacji, możesz użyć właściwości matchingFallbacks
, aby kierować reklamy tylko na warianty, które chcesz przetestować. Zapobiega to też konieczności samodzielnego konfigurowania tych wariantów przez moduł testowy.