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

Тестирование в 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. Исходный код приложения и соответствующие тестовые файлы инструментов.

Как и в случае с наборами исходных текстов вашего приложения, сборка Gradle объединяет и переопределяет файлы из разных наборов исходных текстов тестов. В этом случае файл AndroidExampleTest.java в исходном наборе androidTestMyFlavor переопределяет версию в исходном наборе androidTest . Это связано с тем, что исходный набор вариантов продукта имеет приоритет над основным исходным набором.

Когда вы выбираете разные варианты в селекторе вариантов сборки, соответствующие папки androidTest отображаются в представлении Android , чтобы показать используемые папки:

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

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

Если выбран другой вариант, папка 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:

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:

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