Testar seu app

O Android Studio foi projetado para facilitar testes. Com apenas alguns cliques, você pode configurar um teste do JUnit executado na JVM local ou um teste de instrumentação executado em um dispositivo. Naturalmente, é possível ampliar os recursos de teste integrando estruturas como o Mockito para testar chamadas de API do Android em testes de unidade locais e o Espresso ou o UI Automator para simular a interação do usuário nos testes de instrumentação. Você pode gerar testes do Espresso automaticamente usando o Espresso Test Recorder.

Esta página oferece informações básicas sobre como adicionar novos testes ao app e executá-los no Android Studio.

Para ver um guia de instruções mais completo sobre a programação de testes, consulte Testar apps no Android.

Tipos e localização de testes

A localização do código de teste depende do tipo de teste criado. O Android Studio oferece diretórios de código-fonte (conjuntos de origem) para os dois tipos de teste a seguir:

Testes de unidade locais

Localizados em module-name/src/test/java/.

Esses testes são executados na Java Virtual Machine (JVM) local do computador. Eles são usados para minimizar o tempo de execução quando os testes não têm dependências de estrutura Android ou quando você consegue simular essas dependências.

No ambiente de execução, esses testes são executados em uma versão modificada do android.jar, em que todos os modificadores final foram removidos. Isso permite usar bibliotecas de simulação conhecidas, como o Mockito.

Testes de instrumentação

Localizados em module-name/src/androidTest/java/.

São testes executados em um dispositivo ou emulador de hardware. Esses testes têm acesso às APIs Instrumentation, dão acesso a informações como o Context do app em teste e permitem controlar o app sendo testado a partir do código de teste. Eles são usados na programação de testes de integração e funcionalidade de IU para automatizar a interação do usuário ou quando os testes têm dependências do Android que os objetos simulados não conseguem satisfazer.

Como os testes de instrumentação são compilados em um APK (separado do APK do app), eles precisam ter o próprio arquivo AndroidManifest.xml. No entanto, o Gradle gera automaticamente esse arquivo durante a compilação, por isso ele não pode ser visto no conjunto de origem do projeto. Se necessário, você pode adicionar o próprio arquivo de manifesto, por exemplo, para especificar um valor diferente para "minSdkVersion" ou registrar listeners de execução exclusivos para seus testes. Na compilação do app, o Gradle mescla vários arquivos de manifesto em um único manifesto.

A compilação do Gradle interpreta esses conjuntos de origem de teste da mesma forma que interpreta os conjuntos de origem de app do projeto, o que permite criar testes de acordo com as variações de compilação.

Quando você cria um novo projeto ou adiciona um módulo de app, o Android Studio cria os conjuntos de origem de teste listados acima e inclui uma amostra de arquivo de teste em cada um deles. É possível vê-los na janela Project, como mostrado na figura 1.

Figura 1. Os (1) testes de instrumentação e os (2) testes da JVM local do projeto podem ser encontrados nas visualizações Project (à esquerda) ou Android (à direita).

Adicionar um novo teste

Para criar um teste de unidade local ou um teste de instrumentação, você pode criar um novo teste para uma classe ou método específico seguindo estas etapas:

  1. Abra o arquivo Java que contém o código que você quer testar.
  2. Clique na classe ou no método que você quer testar e pressione Ctrl+Shift+T (⇧⌘T).
  3. No menu exibido, clique em Create New Test.
  4. Na caixa de diálogo Create Test, edite os campos necessários, selecione os métodos a serem gerados e clique em OK.
  5. Na caixa de diálogo Choose Destination Directory, clique no conjunto de origem correspondente ao tipo de teste que você quer criar: androidTest para um teste de instrumentação ou test para um teste de unidade local. Clique em OK.

Como alternativa, você pode criar um arquivo Java genérico no conjunto de origem de teste adequado da seguinte forma:

  1. Na janela Project à esquerda, clique no menu suspenso e selecione a visualização Project.
  2. Amplie a pasta do módulo adequado e a pasta src aninhada. Para adicionar um teste de unidade local, amplie a pasta test e a pasta java aninhada. Para adicionar um teste de instrumentação, amplie a pasta androidTest e a pasta java aninhada.
  3. Clique com o botão direito no diretório do pacote Java e selecione New > Java Class.
  4. Atribua um nome ao arquivo e clique em OK.

Especifique também as dependências de biblioteca de teste no arquivo build.gradle do módulo do app:

dependencies {
        // Required for local unit tests (JUnit 4 framework)
        testImplementation 'junit:junit:4.12'

        // Required for instrumented tests
        androidTestImplementation 'com.android.support:support-annotations:24.0.0'
        androidTestImplementation 'com.android.support.test:runner:0.5'
    }
    

Para ver outras dependências de biblioteca e mais informações sobre como programar testes, consulte Compilar testes de unidade locais e Compilar testes de instrumentação de unidade.

Resolver conflitos entre o app e o APK de teste

O APK do seu app e o APK de teste correspondente têm os mesmos caminhos de classe. Sendo assim, você poderá receber um erro de compilação se os dois APKs dependerem de versões diferentes da mesma biblioteca. Se o Gradle não conseguir detectar esse conflito de versão, o app poderá se comportar de maneira inesperada ou travar durante o tempo de execução.

Para saber mais, consulte Corrigir erros de resolução de dependência.

Criar um teste de instrumentação para uma variação de compilação

Se o projeto incluir variações de compilação com conjuntos de origem únicos, você poderá precisar de conjuntos de origem de teste de instrumentação correspondentes. A criação de testes de instrumentação em conjuntos de origem correspondentes às suas variações de compilação ajudará a manter o código organizado e permitirá executar apenas os testes necessários para uma determinada variação.

Para adicionar um conjunto de origem de teste à sua variação de compilação, siga estas etapas:

  1. Na janela Project à esquerda, clique no menu suspenso e selecione a visualização Project.
  2. Na pasta do módulo adequado, clique com o botão direito na pasta src e depois em New > Directory.
  3. Como nome do diretório, insira "androidTestVariantName". Por exemplo, se você tem uma variação de compilação denominada "MyFlavor", o nome do diretório deverá ser "androidTestMyFlavor". Clique em OK.
  4. Clique com o botão direito no novo diretório e depois em New > Directory.
  5. Nomeie o diretório como "java" e clique em OK.

Agora você pode adicionar testes a esse novo conjunto de origem seguindo as etapas acima. Quando vir a caixa de diálogo Choose Destination Directory, selecione o novo conjunto de origem de teste da variação.

Os testes de instrumentação no conjunto de origem src/androidTest/ são compartilhados por todas as variações de compilação. Na compilação de um APK de teste para a variação "MyFlavor" do app, o Gradle combina os conjuntos de origem src/androidTest/ e src/androidTestMyFlavor/.

Por exemplo, a tabela a seguir mostra como os arquivos de teste de instrumentação devem ficar nos conjuntos de origem correspondentes aos do código do app.

Caminho para a classe do app Caminho para a classe de teste de instrumentação correspondente
src/main/java/Foo.java src/androidTest/java/AndroidFooTest.java
src/myFlavor/java/Foo.java src/androidTestMyFlavor/java/AndroidFooTest.java

Da mesma forma que nos conjuntos de origem do app, a compilação do Gradle mescla e modifica arquivos de diferentes conjuntos de origem de teste. Nesse caso, o arquivo AndroidFooTest.java no conjunto de origem "androidTestMyFlavor" modifica a versão no conjunto de origem "androidTest". Para mais informações sobre como os conjuntos de origem são mesclados, consulte Configurar sua compilação.

Outro motivo para usar variações de compilação para os conjuntos de origem do app e de teste é a criação de testes herméticos por meio de dependências simuladas. Ou seja, você pode criar uma variação de produto para o app contendo implementações falsas de dependências, como solicitações de rede ou dados de sensor do dispositivo que normalmente são instáveis, e adicionar um conjunto de origem de teste simulado correspondente. Para ver mais informações, consulte a postagem do blog sobre o uso de variações de produto para testes herméticos.

Definir configurações do manifesto de instrumentação

Quando o Gradle compila seu APK de teste, ele gera automaticamente o arquivo AndroidManifest.xml e o configura com o nó <instrumentation>. Um dos motivos por que o Gradle configura esse nó é garantir que a propriedade targetPackage especifique o nome de pacote correto do app em teste. Você pode alterar algumas das configurações desse nó criando outro arquivo de manifesto no conjunto de origem de teste ou configurando seu arquivo build.gradle no nível do módulo, conforme mostrado no exemplo de código a seguir:

    android {
      ...
      // Each product flavor you configure can override properties in the
      // defaultConfig {} block. To learn more, go to Configure product flavors.
      defaultConfig {
        ...
        // Specifies the application ID for the test APK.
        testApplicationId "com.test.foo"
        // Specifies the fully-qualified class name of the test instrumentation runner.
        testInstrumentationRunner "android.test.InstrumentationTestRunner"
        // If set to 'true', enables the instrumentation class to start and stop profiling.
        // If set to false (default), profiling occurs the entire time the instrumentation
        // class is running.
        testHandleProfiling true
        // If set to 'true', indicates that the Android system should run the instrumentation
        // class as a functional test. The default value is 'false'
        testFunctionalTest true
      }
    }
    ...
    

Alterar o tipo de compilação de teste

Por padrão, todos os testes são executados com o tipo de compilação de depuração. Para mudar o tipo de compilação, use a propriedade testBuildType no arquivo build.gradle no nível do módulo. Por exemplo, se você quiser executar os testes com o tipo de compilação "staging", edite o arquivo conforme mostrado no snippet a seguir:

android {
        ...
        testBuildType "staging"
    }
    

Configurar opções de teste do Gradle

O plug-in do Android para Gradle permite especificar determinadas opções para todos os testes de unidade ou para apenas alguns deles. No arquivo build.gradle no nível do módulo, use o bloco testOptions {} para especificar opções que alteram a forma como o Gradle executa todos os testes.

    android {
      ...
      // Encapsulates options for running tests.
      testOptions {
        // Changes the directory where Gradle saves test reports. By default, Gradle saves test reports
        // in the path_to_your_project/module_name/build/outputs/reports/ directory.
        // '$rootDir' sets the path relative to the root directory of the current project.
        reportDir "$rootDir/test-reports"
        // Changes the directory where Gradle saves test results. By default, Gradle saves test results
        // in the path_to_your_project/module_name/build/outputs/test-results/ directory.
        // '$rootDir' sets the path relative to the root directory of the current project.
        resultsDir "$rootDir/test-results"
      }
    }
    

Para especificar opções específicas para testes de unidade locais, configure o bloco unitTests {} dentro de testOptions {}.

    android {
      ...
      testOptions {
        ...
        // Encapsulates options for local unit tests.
        unitTests {
          // By default, local unit tests throw an exception any time the code you are testing tries to access
          // Android platform APIs (unless you mock Android dependencies yourself or with a testing
          // framework like Mockito). However, you can enable the following property so that the test
          // returns either null or zero when accessing platform APIs, rather than throwing an exception.
          returnDefaultValues true

          // Encapsulates options for controlling how Gradle executes local unit tests. For a list
          // of all the options you can specify, read Gradle's reference documentation.
          all {
            // Sets JVM argument(s) for the test JVM(s).
            jvmArgs '-XX:MaxPermSize=256m'

            // You can also check the task name to apply options to only the tests you specify.
            if (it.name == 'testDebugUnitTest') {
              systemProperty 'debug', 'true'
            }
            ...
          }
        }
      }
    }
    

Usar módulos de teste diferentes para testes de instrumentação

Se você quer usar um módulo dedicado para testes de instrumentação e isolar o restante do código dos seus testes, crie um módulo de teste separado e configure a compilação 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 de compilação no nível do módulo, aplique o plug-in com.android.test em vez de com.android.library.
  3. Sincronize seu projeto.

Depois de criar seu módulo de teste, é possível incluir o código no conjunto de origem principal ou de variação, por exemplo, src/main/java ou src/variant/java. Se o módulo do app define diversas variações de produto, você pode recriar essas variações no módulo de teste e, 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 variação debug. No entanto, você pode criar novos tipos de compilação que correspondam ao projeto de app testado. Para fazer o módulo testar outro tipo de compilação que não o de depuração, use VariantFilter para desativar a variação debug no projeto de teste, conforme mostrado abaixo:

android {
        variantFilter { variant ->
            if (variant.buildType.name.equals('debug')) {
                variant.setIgnore(true);
            }
        }
    }
    

Se você quer que um módulo de teste seja destinado a apenas determinadas variações de produto ou tipos de compilação de um app, use a propriedade matchingFallbacks para segmentar apenas as variações de compilação que você quer testar. Isso também evita que o módulo de teste tenha que configurar essas variações por conta própria.

Executar um teste

Para executar um teste, faça o seguinte:

  1. Verifique se o projeto está sincronizado com o Gradle clicando em Sync Project , na barra de ferramentas.
  2. Execute o teste de uma das seguintes formas:
    • Na janela Project, clique com o botão direito em um teste e depois em Run .
    • No Code Editor, clique com o botão direito em uma classe ou um método no arquivo de teste e depois em Run para testar todos os métodos da classe.
    • Para executar todos os testes, clique com o botão direito no diretório de teste e depois em Run tests .

Por padrão, o teste é executado por meio da configuração de execução padrão do Android Studio. Se você quiser alterar algumas configurações de execução, como as opções de executor e implantação de instrumentação, faça as edições necessárias na caixa de diálogo Run/Debug Configurations (clique em Run > Edit Configurations).

Ver cobertura de teste

A ferramenta de cobertura de teste está disponível para que testes de unidade locais monitorem a porcentagem e as áreas do código do app cobertas pelos testes de unidade. Use a ferramenta de cobertura de teste para determinar se você testou corretamente os elementos, classes, métodos e linhas de código que compõem seu app.

Existem diversas maneiras de executar um teste de unidade, e elas estão descritas na página do IntelliJ Executar com cobertura (link em inglês). O procedimento a seguir mostra como executar um teste de unidade em linha no editor:

  1. Clique duas vezes no teste de unidade que você quer executar.
  2. No editor, coloque o cursor na linha que você quer executar com cobertura.
    • Se você colocar o cursor na declaração de classe, todos os métodos de teste dessa classe serão executados.
    • Se você colocar o cursor em uma declaração de método, todos o código desse método será executado.
    • Se você colocar o cursor em uma linha específica dentro de um método, apenas essa linha será executada.
  3. Clique com o botão direito na linha em que você colocou o cursor.
  4. No menu de contexto, escolha Run test-name with coverage.

    A janela de ferramenta de cobertura será exibida.

A figura 2 mostra a janela de ferramenta de cobertura de um teste de unidade de calculadora que testa somas, subtrações, multiplicações e divisões.

Figura 2. Veja as porcentagens de cobertura de código do seu aplicativo.

Para ver mais informações sobre testes de unidade locais, consulte Compilar testes de unidade locais.

Ver os resultados do teste

Quando você executa um teste JUnit ou de instrumentação, os resultados são exibidos na janela Run. Uma barra verde significa que todos os testes foram bem-sucedidos, enquanto uma barra vermelha significa que pelo menos um deles falhou. A figura 3 mostra um teste bem-sucedido.

Figura 3. Os resultados do teste são exibidos na janela "Run".

A janela Run exibe os testes em uma visualização em árvore à esquerda, e os resultados e mensagens do conjunto de testes atual no painel à direita. Use as barras de ferramentas, menus de contexto e ícones de status para gerenciar os resultados do teste, da seguinte maneira:

  1. Use a barra de ferramentas de execução para executar novamente ou interromper o teste atual, executar novamente testes com falha (essa opção não é exibida porque só está disponível para testes de unidade), pausar a saída e fazer o despejo de linhas de execução.
  2. Use a barra de ferramentas de testes para filtrar e classificar os resultados. Você também pode expandir ou recolher nós, mostrar a cobertura do teste e importar ou exportar os resultados.
  3. Clique no menu de contexto para acompanhar o teste em execução, exibir estatísticas em linha, rolar para a stack trace, abrir o código-fonte em uma exceção, rolar automaticamente até a origem e selecionar o primeiro teste com falha quando a execução do teste terminar.
  4. Os ícones de status de teste indicam se um teste tem um erro, foi ignorado, falhou, está em andamento, terminou, está parado, foi cancelado ou não foi executado.
  5. Clique com o botão direito em uma linha na visualização em árvore para exibir um menu de contexto que permite executar testes no modo de depuração. Abra o arquivo de código-fonte do teste ou vá para a linha do código-fonte que está sendo testada.

Para mais informações sobre a janela Run ou sobre as barras de ferramentas e os menus de contexto que ela oferece, consulte a página do IntelliJ Guia Test Runner (link em inglês).

Visualizar estatísticas em linha

Para saber quanto tempo seus testes levaram para ser executados, siga estas etapas:

  1. Clique no ícone de engrenagem .
  2. Na lista suspensa, selecione Show Inline Statistics.

    O tempo decorrido, em milésimos de segundo, é exibido à direita dos testes.

Comparar strings

Se um teste de unidade apresentar falhas assertEquals() ao comparar dois objetos de string, você poderá ver as diferenças entre esses dois objetos e saber o motivo das falhas da seguinte forma:

  1. No painel de saída, clique no link Click to see the difference.
  2. No Differences viewer, analise as diferenças conforme descrito na página do IntelliJ Differences viewer para arquivos (link em inglês).

Exportar resultados de teste

Você pode exportar os resultados de um teste nos formatos XML ou HTML da seguinte maneira:

  1. Clique em Export Test Results .
  2. Na caixa de diálogo Export Test Results, insira as informações de formato e saída e clique em OK.

    Os resultados de teste exportados são salvos na pasta especificada.

Importar resultados de teste

Você pode importar os resultados de um teste da seguinte maneira:

  1. Clique em Import Test Results .
  2. No menu suspenso, selecione o arquivo que você quer importar.

    Os resultados de teste importados são exibidos na janela Run.