Configuração de testes avançados

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:

1. Na janela Project, clique no menu e selecione a visualização Project.
2. Na pasta do módulo adequado, clique com o botão direito do mouse na pasta src e depois em New > Directory.
3. 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.
4. Clique em OK.
5. Clique com o botão direito do mouse no diretório e selecione New > Directory.
6. 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:

Figura 1. A variante MyFlavor selecionada. A pasta androidTestMyFlavor aparece na visualização Android.

A pasta androidTestMyFlavor não aparece quando uma variante diferente é selecionada:

Figura 2. 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:

Figura 3. A variante 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:

Figura 4. 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:

1. Crie um módulo de biblioteca.
2. No arquivo build.gradle de módulo, aplique o plug-in com.android.test em vez de com.android.library.
3. 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.