Расширенная настройка теста

Тестирование в Android Studio и Тестирование из командной строки объясняют, как настроить и запустить базовые конфигурации тестирования. Однако когда ваше приложение и требования к его тестированию станут более сложными, вам может потребоваться дальнейшая адаптация тестовых конфигураций. Например, вам может потребоваться расширенная настройка теста, если вы хотите выполнить следующее:

  • Запускайте инструментальные тесты только для определенного варианта сборки или переопределите его настройки манифеста.
  • Измените тип сборки, на которой выполняются ваши тесты, или настройте его параметры Gradle.
  • Извлеките инструментированные тесты в отдельный тестовый модуль.
  • Выполните более расширенное тестирование в рамках настройки непрерывной интеграции.

На этой странице описаны различные способы настройки тестов, если настройки по умолчанию не соответствуют вашим потребностям.

Создайте инструментированный тест для варианта сборки.

Если ваш проект включает варианты сборки с уникальными наборами исходного кода, возможно, вы захотите включить инструментированные тесты, соответствующие этим наборам исходного кода. Это обеспечивает организованность тестового кода и позволяет запускать только те тесты, которые применимы к данному варианту сборки.

Чтобы связать инструментированные тесты с вариантом сборки, поместите их в отдельный набор исходного кода, расположенный по адресу src/androidTest VariantName .

Инструментированные тесты в исходном наборе src/androidTest/ являются общими для всех вариантов сборки. При создании тестового APK для варианта вашего приложения «MyFlavor» Gradle объединяет наборы исходных кодов src/androidTest/ и src/androidTestMyFlavor/ .

Чтобы добавить набор исходных кодов тестирования для вашего варианта сборки в Android Studio, выполните следующие действия:

  1. В окне «Проект» щелкните меню и выберите представление «Проект» .
  2. В соответствующей папке модуля щелкните правой кнопкой мыши папку src и выберите «Создать» > «Каталог» .
  3. В качестве имени каталога введите «androidTest VariantName ». Например, если у вас есть вариант сборки под названием «MyFlavor», используйте имя каталога androidTestMyFlavor .
  4. Нажмите ОК .
  5. Щелкните правой кнопкой мыши новый каталог и выберите «Создать» > «Каталог» .
  6. Введите «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.
Рисунок 1. Выбран вариант MyFlavor ; папка androidTestMyFlavor отображается в представлении Android .

Папка androidTestMyFlavor не отображается, если выбран другой вариант:

Выбран вариант OtherFlavor, и папка androidTestMyFlavor не отображается в представлении Android.
Рисунок 2. Выбран вариант OtherFlavor ; папка androidTestMyFlavor не отображается в представлении Android .

Это выглядит немного иначе, если вы используете представление «Проект» , но применяется тот же принцип:

Выбран вариант MyFlavor, и папка androidTestMyFlavor активна в представлении проекта.
Рисунок 3. Выбран вариант MyFlavor ; папка androidTestMyFlavor активна в представлении «Проект» .

Если выбран другой вариант, папка androidTestMyFlavor по-прежнему видна, но не отображается как активная:

Выбран вариант OtherFlavor, и папка androidTestMyFlavor не активна в представлении проекта.
Рисунок 4. Выбран вариант 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 .

Используйте отдельные тестовые модули для инструментальных тестов.

Если вы хотите иметь специальный модуль для инструментальных тестов, чтобы изолировать остальную часть вашего кода от тестов, создайте отдельный тестовый модуль и настройте его сборку аналогично библиотечному модулю.

Чтобы создать тестовый модуль, выполните следующие действия:

  1. Создайте библиотечный модуль .
  2. В файле build.gradle уровня модуля примените плагин com.android.test вместо com.android.library .
  3. Нажмите «Синхронизировать проект». .

После создания тестового модуля вы можете включить тестовый код в основной или вариантный набор исходного кода (например, 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 , чтобы ориентироваться только на те варианты, которые вы хотите протестировать. Это также избавляет тестовый модуль от необходимости настраивать эти варианты самостоятельно.