Тестирование в Android Studio и Тестирование из командной строки объясняют, как настроить и запустить базовые конфигурации тестирования. Однако когда ваше приложение и требования к его тестированию станут более сложными, вам может потребоваться дальнейшая адаптация тестовых конфигураций. Например, вам может потребоваться расширенная настройка теста, если вы хотите выполнить следующее:
- Запускайте инструментальные тесты только для определенного варианта сборки или переопределите его настройки манифеста.
- Измените тип сборки, на которой выполняются ваши тесты, или настройте его параметры Gradle.
- Извлеките инструментированные тесты в отдельный тестовый модуль.
- Выполните более расширенное тестирование в рамках настройки непрерывной интеграции.
На этой странице описаны различные способы настройки тестов, если настройки по умолчанию не соответствуют вашим потребностям.
Создайте инструментированный тест для варианта сборки.
Если ваш проект включает варианты сборки с уникальными наборами исходного кода, возможно, вы захотите включить инструментированные тесты, соответствующие этим наборам исходного кода. Это обеспечивает организованность тестового кода и позволяет запускать только те тесты, которые применимы к данному варианту сборки.
Чтобы связать инструментированные тесты с вариантом сборки, поместите их в отдельный набор исходного кода, расположенный по адресу src/androidTest VariantName
.
Инструментированные тесты в исходном наборе src/androidTest/
являются общими для всех вариантов сборки. При создании тестового APK для варианта вашего приложения «MyFlavor» Gradle объединяет наборы исходных кодов src/androidTest/
и src/androidTestMyFlavor/
.
Чтобы добавить набор исходных кодов тестирования для вашего варианта сборки в Android Studio, выполните следующие действия:
- В окне «Проект» щелкните меню и выберите представление «Проект» .
- В соответствующей папке модуля щелкните правой кнопкой мыши папку src и выберите «Создать» > «Каталог» .
- В качестве имени каталога введите «androidTest VariantName ». Например, если у вас есть вариант сборки под названием «MyFlavor», используйте имя каталога
androidTestMyFlavor
. - Нажмите ОК .
- Щелкните правой кнопкой мыши новый каталог и выберите «Создать» > «Каталог» .
- Введите «java» в качестве имени каталога, затем нажмите «ОК» .
Теперь вы можете добавить тесты в этот новый исходный набор, выполнив действия по добавлению нового теста . Когда вы дойдете до диалогового окна «Выбор целевого каталога» , выберите новый набор вариантов тестового источника.
В следующей таблице показан пример того, как файлы инструментального тестирования могут находиться в наборах исходного кода, соответствующих наборам исходного кода приложения.
Таблица 1. Исходный код приложения и соответствующие тестовые файлы инструментов.
Путь к классу приложения | Путь к соответствующему классу испытаний приборов |
---|---|
src/main/java/Example.java | src/androidTest/java/AndroidExampleTest.java |
src/myFlavor/java/Example.java | src/androidTestMyFlavor/java/AndroidExampleTest.java |
Как и в случае с наборами исходных кодов вашего приложения, сборка Gradle объединяет и переопределяет файлы из разных наборов исходных текстов тестов. В этом случае файл AndroidExampleTest.java
в исходном наборе androidTestMyFlavor
переопределяет версию в исходном наборе androidTest
. Это связано с тем, что исходный набор вариантов продукта имеет приоритет над основным исходным набором.
Когда вы выбираете разные варианты в селекторе вариантов сборки, соответствующие папки androidTest
отображаются в представлении Android , чтобы показать используемые папки:
![Выбран вариант MyFlavor, и папка androidTestMyFlavor отображается в представлении Android.](https://developer.android.google.cn/static/studio/images/test/test-myflavor-android-test-android-view.png?authuser=0000&hl=ru)
MyFlavor
; папка androidTestMyFlavor
отображается в представлении Android . Папка androidTestMyFlavor
не отображается, если выбран другой вариант:
![Выбран вариант OtherFlavor, и папка androidTestMyFlavor не отображается в представлении Android.](https://developer.android.google.cn/static/studio/images/test/test-otherflavor-android-test-android-view.png?authuser=0000&hl=ru)
OtherFlavor
; папка androidTestMyFlavor
не отображается в представлении Android .Это выглядит немного иначе, если вы используете представление «Проект» , но применяется тот же принцип:
![Выбран вариант MyFlavor, и папка androidTestMyFlavor активна в представлении проекта.](https://developer.android.google.cn/static/studio/images/test/test-myflavor-android-test-project-view.png?authuser=0000&hl=ru)
MyFlavor
; папка androidTestMyFlavor
активна в представлении «Проект» . Если выбран другой вариант, папка androidTestMyFlavor
по-прежнему видна, но не отображается как активная:
![Выбран вариант OtherFlavor, и папка androidTestMyFlavor не активна в представлении проекта.](https://developer.android.google.cn/static/studio/images/test/test-otherflavor-android-test-project-view.png?authuser=0000&hl=ru)
OtherFlavor
; папка androidTestMyFlavor
неактивна в представлении «Проект» .Дополнительные сведения об объединении исходных наборов см. в разделе «Исходные наборы» .
Настройка параметров манифеста инструментария
Инструментальные тесты встроены в отдельный APK с собственным файлом AndroidManifest.xml
. Когда Gradle собирает тестовый APK, он автоматически генерирует файл AndroidManifest.xml
и настраивает его с помощью узла <instrumentation>
. Одна из причин, по которой Gradle настраивает этот узел для вас, — убедиться, что свойство targetPackage
указывает правильное имя пакета тестируемого приложения.
Чтобы изменить другие параметры для этого узла, либо создайте еще один файл манифеста в наборе исходного кода теста, либо настройте файл build.gradle
на уровне модуля, как показано в следующем примере кода. Полный список опций можно найти в справочнике по API BaseFlavor
.
классный
android { ... defaultConfig { ... testApplicationId "com.example.test" testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner" testHandleProfiling true testFunctionalTest true } }
Котлин
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" }
Котлин
android { ... testBuildType = "staging" }
Настройка параметров теста Gradle
Плагин Android Gradle позволяет вам указать определенные параметры для всех или только для некоторых ваших тестов. В файле build.gradle
на уровне модуля используйте блок testOptions
, чтобы указать параметры, которые изменяют способ запуска всех ваших тестов Gradle:
классный
android { ... // Encapsulates options for running tests. testOptions { reportDir "$rootDir/test-reports" resultsDir "$rootDir/test-results" } }
Котлин
android { ... // Encapsulates options for running tests. testOptions { reportDir "$rootDir/test-reports" resultsDir = "$rootDir/test-results" } }
Свойство reportDir
изменяет каталог, в котором Gradle сохраняет отчеты о тестировании. По умолчанию Gradle сохраняет отчеты о тестировании в каталоге path_to_your_project / module_name /build/outputs/reports/
. $rootDir
устанавливает путь относительно корневого каталога текущего проекта.
Свойство resultsDir
изменяет каталог, в котором Gradle сохраняет результаты тестов. По умолчанию Gradle сохраняет результаты тестов в каталоге path_to_your_project / module_name /build/outputs/test-results/
. $rootDir
устанавливает путь относительно корневого каталога текущего проекта.
Чтобы указать параметры только для локальных модульных тестов, настройте блок unitTests
внутри testOptions
.
классный
android { ... testOptions { ... // Encapsulates options for local unit tests. unitTests { returnDefaultValues true all { jvmArgs '-XX:MaxPermSize=256m' if (it.name == 'testDebugUnitTest') { systemProperty 'debug', 'true' } ... } } } }
Котлин
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") } ... } } } }
По умолчанию локальные модульные тесты выдают исключение каждый раз, когда тестируемый код пытается получить доступ к API-интерфейсам платформы Android, если только вы не имитируете зависимости Android самостоятельно или с помощью платформы тестирования, такой как Mockito. Однако вы можете включить свойство returnDefaultValues
, чтобы тест возвращал значение NULL или ноль при доступе к API платформы, а не выдавал исключение.
Блок all
инкапсулирует параметры управления тем, как Gradle выполняет локальные модульные тесты. Список всех параметров, которые вы можете указать, можно найти в справочной документации Gradle .
Свойство jvmArgs
устанавливает аргументы JVM для тестовых JVM.
Вы также можете проверить имя задачи, чтобы применить параметры только к указанным вами тестам. В фрагменте примера для свойства debug
установлено значение true
, но только для задачи testDebugUnitTest
.
Используйте отдельные тестовые модули для инструментальных тестов.
Если вы хотите иметь специальный модуль для инструментальных тестов, чтобы изолировать остальную часть вашего кода от тестов, создайте отдельный тестовый модуль и настройте его сборку аналогично библиотечному модулю.
Чтобы создать тестовый модуль, выполните следующие действия:
- Создайте библиотечный модуль .
- В файле
build.gradle
уровня модуля примените плагинcom.android.test
вместоcom.android.library
. - Нажмите «Синхронизировать проект».
.
После создания тестового модуля вы можете включить тестовый код в основной или вариантный набор исходного кода (например, src/main/java
или src/ variant /java
). Если ваш модуль приложения определяет несколько вариантов продукта, вы можете воссоздать эти варианты в своем тестовом модуле. Используя управление зависимостями с учетом вариантов , тестовый модуль пытается проверить соответствующий вариант в целевом модуле.
По умолчанию тестовые модули содержат и тестируют только отладочный вариант. Однако вы можете создавать новые типы сборок, соответствующие тестируемому проекту приложения. Чтобы тестовый модуль тестировал другой тип сборки, а не отладочный, используйте VariantFilter
, чтобы отключить вариант отладки в тестовом проекте, как показано:
классный
android { variantFilter { variant -> if (variant.buildType.name.equals('debug')) { variant.setIgnore(true); } } }
Котлин
android { variantFilter { if (buildType.name == "debug") { ignore = true } } }
Если вы хотите, чтобы тестовый модуль предназначался только для определенных вариантов или типов сборки приложения, вы можете использовать свойство matchingFallbacks
, чтобы ориентироваться только на те варианты, которые вы хотите протестировать. Это также избавляет тестовый модуль от необходимости настраивать эти варианты самостоятельно.