Testar no Android Studio e Testar na linha de comando explicam como definir e executar configurações básicas de teste. No entanto, quando o app e os requisitos de teste forem mais avançados, talvez seja necessário adaptar ainda mais as configurações. Por exemplo, talvez você precise configurar um teste avançado quando quiser:
- executar testes de instrumentação somente para uma variante de build específica ou substituir as configurações do manifesto;
- mudar o tipo de build em que os testes são executados ou configurar as opções do Gradle;
- extrair seus testes instrumentados no próprio módulo de teste;
- realizar testes mais avançados como parte da configuração da integração contínua.
Esta página descreve várias maneiras de configurar testes quando as configurações padrão não atenderem às suas necessidades.
Criar um teste instrumentado para uma variante de build
Se o projeto incluir variantes de build com conjuntos de origem únicos, convém incluir testes de instrumentação correspondentes. Isso mantém o código de teste organizado e permite executar apenas os testes que se aplicam a uma variante de build específica.
Para vincular testes de instrumentação a uma variante de build, coloque-os no próprio
conjunto de origem, localizado em
src/androidTestVariantName
.
Os testes de instrumentação no conjunto de origem src/androidTest/
são compartilhados por todas as
variantes de build. Ao criar um APK de teste para a variante "MyFlavor" do app,
o Gradle combina os conjuntos de origem
src/androidTest/
e src/androidTestMyFlavor/
.
Para adicionar um conjunto de origem de teste à sua variante de build no Android Studio, siga estas etapas:
- Na janela Project, clique no menu e selecione a visualização Project.
- Na pasta do módulo adequado, clique com o botão direito do mouse na pasta src e depois em New > Directory.
- Para o nome do diretório, digite "androidTestVariantName". Por exemplo, se
você tiver uma variante de build denominada "MyFlavor", use o nome de diretório
androidTestMyFlavor
. - Clique em OK.
- Clique com o botão direito do mouse no diretório e selecione New > Directory.
- Nomeie o diretório como "java" e clique em OK.
Agora você pode adicionar testes a esse novo conjunto de origem seguindo as etapas para adicionar um novo teste. Quando a caixa de diálogo Choose Destination Directory aparecer, selecione o novo conjunto de origem de teste da variante.
Na tabela abaixo, mostramos um exemplo de como os arquivos de teste de instrumentação podem ficar nos conjuntos de origem correspondentes aos do código do app.
Tabela 1. O código-fonte do app e os arquivos de teste de instrumentação correspondentes.
Caminho para a classe do app | Caminho para a classe de teste de instrumentação correspondente |
---|---|
src/main/java/Example.java
|
src/androidTest/java/AndroidExampleTest.java
|
src/myFlavor/java/Example.java
|
src/androidTestMyFlavor/java/AndroidExampleTest.java
|
Da mesma forma que nos conjuntos de origem do app, o build do Gradle mescla e
modifica arquivos de diferentes conjuntos de origem de teste. Nesse caso, o arquivo
AndroidExampleTest.java
no conjunto de origem androidTestMyFlavor
substitui
a versão no conjunto de origem androidTest
. Isso ocorre porque
o conjunto de origem da variação de produto tem prioridade sobre o conjunto de origem principal.
Quando você seleciona variações diferentes no seletor de variantes de build, as
pastas androidTest
apropriadas aparecem na visualização Android para
mostrar as pastas usadas:
![A variante MyFlavor selecionada e a pasta androidTestMyFlavor são mostradas
na visualização do Android.](https://developer.android.com/static/studio/images/test/test-myflavor-android-test-android-view.png?authuser=0000&hl=pt-br)
MyFlavor
selecionada. A
pasta androidTestMyFlavor
aparece na visualização Android.A pasta androidTestMyFlavor
não aparece quando uma variante diferente é
selecionada:
![A variante OtherFlavor selecionada e a pasta androidTestMyFlavor não são
mostradas na visualização do Android.](https://developer.android.com/static/studio/images/test/test-otherflavor-android-test-android-view.png?authuser=0000&hl=pt-br)
OtherFlavor
variante selecionada. A
pasta androidTestMyFlavor
não aparece na visualização Android.Isso vai parecer um pouco diferente se você estiver usando a visualização Project, mas o mesmo princípio se aplica:
![A variante MyFlavor selecionada e a pasta androidTestMyFlavor estão ativas
na visualização Project](https://developer.android.com/static/studio/images/test/test-myflavor-android-test-project-view.png?authuser=0000&hl=pt-br)
MyFlavor
selecionada. A pasta
androidTestMyFlavor
está ativa na visualização Project.Quando uma variante diferente é selecionada, a pasta androidTestMyFlavor
ainda fica
visível, mas não aparece como ativa:
![A variante OtherFlavor selecionada e a pasta androidTestMyFlavor não estão
ativas na visualização Project.](https://developer.android.com/static/studio/images/test/test-otherflavor-android-test-project-view.png?authuser=0000&hl=pt-br)
OtherFlavor
variante selecionada. A
pasta androidTestMyFlavor
não está ativa na visualização Project.Para saber mais sobre como os conjuntos de origem são mesclados, consulte Conjuntos de origem.
Definir configurações do manifesto de instrumentação
Testes de instrumentação são criados em um APK separado, com o próprio arquivo
AndroidManifest.xml
. Quando o Gradle cria seu APK de teste, ele
automaticamente gera o arquivo AndroidManifest.xml
e o configura
com o nó
<instrumentation>
.
Um dos motivos para o Gradle configurar esse nó é garantir que a
propriedade targetPackage
especifique o nome de pacote correto do app em teste.
Para mudar outras configurações desse nó, crie outro
arquivo de manifesto no conjunto de origem de teste ou configure o arquivo
build.gradle
no nível do módulo,
conforme mostrado no
exemplo de código abaixo. A lista completa de opções pode ser encontrada na
referência da API
BaseFlavor
.
Groovy
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" }
Configurar opções de teste do Gradle
O Plug-in do Android para Gradle permite
especificar algumas opções para todos os testes ou apenas alguns deles. No arquivo
build.gradle
de nível de módulo, use o bloco
testOptions
para especificar opções que mudam a forma como o Gradle executa todos os testes.
Groovy
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" } }
A propriedade reportDir
muda o diretório em que o Gradle salva os relatórios
de teste. Por padrão, o Gradle salva os relatórios de teste no diretório
path_to_your_project/module_name
/build/outputs/reports/
. $rootDir
define o caminho relativo
para o diretório raiz do projeto atual.
A propriedade resultsDir
muda o diretório em que o Gradle salva os resultados
do teste. Por padrão, o Gradle salva os resultados do teste no
diretório path_to_your_project/module_name
/build/outputs/test-results/
. $rootDir
define o caminho relativo
para o diretório raiz do projeto atual.
Para especificar opções exclusivas de testes de unidades locais, configure o bloco
unitTests
em testOptions
.
Groovy
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") } ... } } } }
Por padrão, os testes de unidade locais geram uma exceção sempre que o código
que está sendo testado tenta acessar as APIs da Plataforma Android, a menos que você
simule dependências do Android
ou com um framework de teste como o
Mockito. No entanto, você pode ativar a propriedade returnDefaultValues
para que
o teste retorne nulo ou zero ao acessar as APIs da plataforma, em vez de
gerar uma exceção.
O bloco all
encapsula opções para controlar como o Gradle executa
testes de unidade locais. Para uma lista de todas as opções que você pode especificar, leia a
documentação de referência do Gradle (link em inglês).
A propriedade jvmArgs
define os argumentos para as JVMs de teste.
Também é possível verificar o nome da tarefa para aplicar opções apenas nos testes
especificados. No snippet de exemplo, a propriedade debug
está definida como true
, mas
apenas para a tarefa testDebugUnitTest
.
Usar módulos de teste diferentes para testes de instrumentação
Se você quiser ter um módulo dedicado para testes de instrumentação, isole o restante do código dos testes, crie um módulo separado e configure o build de maneira semelhante à de um módulo de biblioteca.
Para criar um módulo de teste, siga estas etapas:
- Crie um módulo de biblioteca.
- No arquivo
build.gradle
de módulo, aplique o plug-incom.android.test
em vez decom.android.library
. - Clique em Sync Project
.
Depois de criar o módulo de teste, é possível incluir o código de teste no
conjunto de origem principal ou variante, como src/main/java
ou
src/variant/java
. Se o módulo do app definir diversas variações de produtos, você vai poder recriá-las
no módulo de teste. Usando o gerenciamento de dependências com
reconhecimento de variantes,
o módulo de teste vai tentar testar a variação correspondente no módulo de destino.
Por padrão, os módulos de teste contêm e testam apenas uma variante de depuração. No entanto,
você pode criar novos tipos de build que correspondam ao projeto de app testado. Para fazer o
módulo testar outro tipo de build que não o de depuração, use
VariantFilter
para desativar a variante no projeto de teste, conforme mostrado abaixo.
Groovy
android { variantFilter { variant -> if (variant.buildType.name.equals('debug')) { variant.setIgnore(true); } } }
Kotlin
android { variantFilter { if (buildType.name == "debug") { ignore = true } } }
Caso queira que um módulo de teste seja direcionado apenas a determinadas variações ou tipos de build de um
app, você poderá usar a propriedade matchingFallbacks
para direcionar apenas as variantes que quer testar. Isso também impede que
o módulo de teste precise configurar essas variantes por conta própria.