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. 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/kotlin+java/Example.kt	src/androidTest/java/AndroidExampleTest.kt
src/myFlavor/kotlin+java/Example.kt	src/androidTestMyFlavor/java/AndroidExampleTest.kt

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.kt 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. variante OtherFlavor selecionada. A pasta androidTestMyFlavor não aparece na visualização Android.

Isso é 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 BaseFlavor referência da API.

Kotlin

android {
    ...
    defaultConfig {
        ...
        testApplicationId = "com.example.test"
        testInstrumentationRunner = "androidx.test.runner.AndroidJUnitRunner"
        testHandleProfiling = true
        testFunctionalTest = true
    }
}

Groovy

android {
    ...
    defaultConfig {
        ...
        testApplicationId "com.example.test"
        testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
        testHandleProfiling true
        testFunctionalTest true
    }
}

Cada variação de produto que você configurar pode modificar as propriedades no bloco defaultConfig {}. Para saber mais, acesse Configurar variações de produtos.

As propriedades do snippet são as seguintes:

Configuração	Descrição
testApplicationId	Especifica o ID do aplicativo para o APK de teste.
testInstrumentationRunner	Especifica o nome totalmente qualificado da classe do executor de instrumentação de teste.
testHandleProfiling	Se definido como true, permite que a classe de instrumentação inicie e pare a criação de perfil. Se definido como false, a criação de perfil vai ocorrer durante todo o tempo em que a classe de instrumentação estiver em execução.
testFunctionalTest	Se definido como true, indica que o sistema Android precisa executar a classe de instrumentação como um teste funcional. O valor padrão é false.

Mudar o tipo de build de teste

Por padrão, todos os testes de instrumentação são executados no tipo de build debug. Para mudar isso para outro tipo de build, use a propriedade testBuildType no arquivo build.gradle de nível de módulo. Por exemplo, se você quiser executar os testes no tipo de build staging, edite o arquivo conforme mostrado no snippet abaixo:

Kotlin

android {
    ...
    testBuildType = "staging"
}

Groovy

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 de nível de módulo, use o bloco para especificar opções que mudam a forma como o Gradle executa todos os testes.build.gradletestOptions

Kotlin

android {
    ...
    // Encapsulates options for running tests.
    testOptions {
        reportDir = "$rootDir/test-reports"
        resultsDir = "$rootDir/test-results"
    }
}

Groovy

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 unitTests bloco em testOptions.

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")
                }
                ...
            }
        }
    }
}

Groovy

android {
    ...
    testOptions {
        ...
        // Encapsulates options for local unit tests.
        unitTests {
            returnDefaultValues true

            all {
                jvmArgs '-XX:MaxPermSize=256m'

                if (it.name == 'testDebugUnitTest') {
                    systemProperty 'debug', '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 (por exemplo, src/main/kotlin+java ou src/variant/kotlin+java). Se o módulo do app definir diversas variações de produtos, você poderá recriá-las no módulo de teste. Usando o gerenciamento de dependências com reconhecimento de variantes, o módulo de teste 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.

Kotlin

android {
    variantFilter {
        if (buildType.name == "debug") {
            ignore = true
        }
    }
}

Groovy

android {
    variantFilter { variant ->
        if (variant.buildType.name.equals('debug')) {
            variant.setIgnore(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.