Testuj w Android Studio oraz Przetestuj z wiersza poleceń – wyjaśnij, jak ustawić i uruchomić podstawowe konfiguracje testowe. Gdy jednak Twoja aplikacja i jej są bardziej zaawansowane, może być konieczne dostosowanie testu konfiguracji. Zaawansowana konfiguracja testów może być potrzebna np. wtedy, gdy chcesz wykonać te czynności:
- Przeprowadzaj testy zinstruowane tylko w przypadku określonego wariantu kompilacji lub zastąp jego ustawieniach pliku manifestu.
- Zmień typ kompilacji, na którym przeprowadzane są testy, lub skonfiguruj Gradle .
- Wyodrębnianie testów zdemontowanych do osobnego modułu testów.
- Przeprowadź bardziej zaawansowane testy w ramach konfiguracji ciągłej integracji.
Na tej stronie opisujemy różne sposoby konfigurowania testów, gdy domyślna które nie odpowiadają Twoim potrzebom.
Tworzenie testu instrumentowanego dla wariantu kompilacji
Jeśli projekt obejmuje warianty kompilacji z parametrem unikalnych zbiorów źródłowych, warto uwzględnić testy instrumentowane, odpowiadającym zbiorom źródłowym. Pozwala to uporządkować kod testowy umożliwia uruchamianie tylko testów, które dotyczą danego wariantu kompilacji.
Aby połączyć testy zinstrumentowane z wariantem kompilacji, umieść je w ich własnym
zbiór źródeł umieszczony na stronie
src/androidTestVariantName
Testy instrumentowane w zbiorze źródłowym src/androidTest/
są udostępniane wszystkim
wariantów kompilacji. Podczas tworzenia testowego pakietu APK dla aplikacji „MyFlavor” wersji
Gradle łączy w sobie src/androidTest/
i src/androidTestMyFlavor/
zbiorów źródłowych.
Aby dodać zestaw źródeł testowych dla wariantu kompilacji w Android Studio, wykonaj te czynności 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 kliknij Nowy > Katalog.
- Jako nazwę katalogu wpisz „androidTestNazwa wariantu”. Na przykład, jeśli
masz wariant kompilacji o nazwie „MyFlavor”, użyj nazwy katalogu
androidTestMyFlavor
- Kliknij OK.
- Kliknij prawym przyciskiem myszy nowy katalog i wybierz New (Nowy) > Katalog.
- Wpisz „java” jako nazwę katalogu, a następnie kliknij OK.
Teraz możesz dodać testy do tego nowego zbioru źródeł, postępując zgodnie z instrukcje dodawania nowego testu. W oknie Choose Target Directory (Wybierz katalog docelowy) wybierz nowy zestaw źródłowy testu wariantu.
W tabeli poniżej znajdziesz przykładowe pliki testowe narzędzi znajdują się w zbiorach źródłowych, które odpowiadają zbiocjom źródłowym kodu aplikacji:
Tabela 1. Kod źródłowy aplikacji i odpowiadający mu kod źródłowy pliki testowe narzędzi
Ścieżka do klasy aplikacji | Ścieżka do pasującej klasy testowej instrumentacji |
---|---|
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ódeł aplikacji, kompilacja Gradle łączy się
zastępuje pliki z różnych zbiorów źródłowych testu. W tym przypadku parametr
AndroidExampleTest.java
plik w zastąpieniach zestawu źródłowego androidTestMyFlavor
wersję w zbiorze źródłowym androidTest
. Dzieje się tak, ponieważ
zbiór źródeł smaków produktu ma wyższy priorytet niż główny zbiór źródeł.
Jeśli w selektorze wariantów wybierzesz różne smaki,
odpowiednie foldery androidTest
są wyświetlane w widoku Androida,
które pliki są używane:
![Wybrano wariant MyFlavor i wyświetlono folder androidTestMyFlavor
w widoku Androida](https://developer.android.com/static/studio/images/test/test-myflavor-android-test-android-view.png?authuser=9&hl=pl)
MyFlavor
wariant;
androidTestMyFlavor
jest wyświetlany w widoku Androida.Folder androidTestMyFlavor
nie jest wyświetlany, gdy występuje inny wariant
wybrano:
![Wybrano wariant OtherFlavor, a folder androidTestMyFlavor nie został wybrany
wyświetlane w widoku Androida](https://developer.android.com/static/studio/images/test/test-otherflavor-android-test-android-view.png?authuser=9&hl=pl)
OtherFlavor
wariant;
Folder androidTestMyFlavor
nie jest widoczny w widoku Android.Sytuacja wygląda trochę inaczej w widoku Projekt, ale jest on taki sam. obowiązuje zasada:
![Wybrano wariant MyFlavor i aktywny folder androidTestMyFlavor
w widoku projektu](https://developer.android.com/static/studio/images/test/test-myflavor-android-test-project-view.png?authuser=9&hl=pl)
MyFlavor
wariant;
Folder androidTestMyFlavor
jest aktywny w widoku Projekt.Jeśli wybierzesz inny wariant, folder androidTestMyFlavor
pozostanie bez zmian
widoczna, ale nie jest wyświetlana jako aktywna:
![Wybrano wariant OtherFlavor, a folder androidTestMyFlavor nie został wybrany
aktywny w widoku projektu](https://developer.android.com/static/studio/images/test/test-otherflavor-android-test-project-view.png?authuser=9&hl=pl)
OtherFlavor
wariant;
Folder androidTestMyFlavor
jest nieaktywny w widoku Projekt.Więcej informacji o scalaniu zbiorów źródłowych znajdziesz w artykule Zbiory źródłowe.
Skonfiguruj ustawienia pliku manifestu instrumentacji
Testy instrumentalne są wbudowane w oddzielny plik APK z osobnym plikiem APK
AndroidManifest.xml
. Gdy Gradle skompiluje testowy plik APK,
automatycznie generuje i konfiguruje plik AndroidManifest.xml
z
<instrumentation>
.
Jednym z powodów, dla których Gradle konfiguruje ten węzeł za Ciebie, jest zapewnienie,
targetPackage
określa prawidłową nazwę pakietu testowanej aplikacji.
Aby zmienić inne ustawienia tego węzła, utwórz
plik manifestu w testowym zestawie źródeł lub skonfiguruj na poziomie modułu
build.gradle
plik, tak jak w tabeli
ten przykładowy kod. Pełną listę opcji znajdziesz w
BaseFlavor
Dokumentacja API.
Odlotowe
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" }
Konfigurowanie opcji testu Gradle
Dzięki wtyczce Androida do obsługi Gradle możesz:
określić opcje dla wszystkich lub tylko niektórych testów. W
build.gradle
na poziomie modułu, użyj funkcji
testOptions
.
blok, aby określić opcje, które zmieniają sposób, w jaki Gradle uruchamia wszystkie testy:
Odlotowe
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 test
raportów. Domyślnie Gradle zapisuje raporty z testów w
Katalog path_to_your_project/module_name
/build/outputs/reports/
. $rootDir
ustawia względną ścieżkę
w katalogu głównym bieżącego projektu.
Właściwość resultsDir
zmienia katalog, w którym Gradle zapisuje test
wyników. Domyślnie Gradle zapisuje wyniki testów w
Katalog path_to_your_project/module_name
/build/outputs/test-results/
. $rootDir
ustawia względną ścieżkę
w katalogu głównym bieżącego projektu.
Aby określić opcje tylko dla lokalnych testów jednostkowych, skonfiguruj parametr
unitTests
w obrębie testOptions
.
Odlotowe
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 kod
próbuje uzyskać dostęp do interfejsów API platformy Androida, chyba że
przykładowe zależności Androida
samodzielnie lub za pomocą platformy testowej,
Mockito. Możesz jednak włączyć właściwość returnDefaultValues
, aby
przy dostępie do interfejsów API platformy test zwraca wartość null lub zero,
niż na zrobienie wyjątku.
Blok all
zawiera opcje umożliwiające kontrolowanie działania Gradle
lokalnych testów jednostkowych. Listę wszystkich dostępnych opcji znajdziesz w artykule
Dokumentacja Gradle
Właściwość jvmArgs
ustawia argumenty JVM dla testowych maszyn wirtualnych.
Możesz też sprawdzić nazwę zadania, aby zastosować opcje tylko do wybranych testów
określić. We przykładowym fragmencie kodu właściwość debug
ma wartość true
, ale
tylko w przypadku zadania testDebugUnitTest
.
Używaj osobnych modułów do testów instrumentowanych
Jeśli chcesz mieć specjalny moduł do testów instrumentowanych, w celu wyodrębnienia reszty kodu z testów, utwórz oddzielny moduł testowy i skonfigurować jego strukturę podobnie do modułu biblioteki.
Aby utworzyć moduł testowy, wykonaj te czynności:
- Utwórz moduł biblioteki.
- W pliku
build.gradle
na poziomie modułu zastosujcom.android.test
. wtyczki zamiastcom.android.library
. - Kliknij Synchronizuj projekt
.
Po utworzeniu modułu testowego możesz umieścić kod testu w sekcji
ustawiono główny element źródła lub wariant źródła (np. src/main/java
lub
src/variant/java
). Jeśli moduł aplikacji określa
różnych smaków, możesz odtworzyć je w module testowym.
Korzystanie z zależności uwzględniającego wariant
,
moduł testowy próbuje sprawdzić rodzaj dopasowania w module docelowym.
Domyślnie moduły testowe zawierają i testują tylko wariant do debugowania. Pamiętaj jednak:
możesz tworzyć nowe typy kompilacji pasujące do testowanego projektu aplikacji. Aby
w module testowym przetestujesz inny typ kompilacji, a nie ten do debugowania, użyj
VariantFilter
, aby wyłączyć wariant debugowania w projekcie testowym:
Odlotowe
android { variantFilter { variant -> if (variant.buildType.name.equals('debug')) { variant.setIgnore(true); } } }
Kotlin
android { variantFilter { if (buildType.name == "debug") { ignore = true } } }
Jeśli chcesz, by moduł testowy był kierowany tylko na niektóre rodzaje lub typy kompilacji
aplikacji, możesz użyć funkcji matchingFallbacks
aby kierować reklamy tylko na warianty, które chcesz przetestować. Zapobiega to także
aby nie trzeba było samodzielnie konfigurować tych wariantów.