O que testar no Android

O teste depende de fatores como o tipo de app, a equipe de desenvolvimento, a quantidade de código legado e a arquitetura usada. As seções a seguir descrevem o que um iniciante pode querer considerar ao planejar o que testar no app.

Organização de diretórios de teste

Um projeto típico no Android Studio contém dois diretórios que contêm testes, dependendo do ambiente de execução. Organize seus testes nos seguintes diretórios, conforme descrito:

  • O diretório androidTest precisa conter os testes executados em dispositivos reais ou virtuais. Esses testes incluem testes de integração, testes completos e outros em que a JVM sozinha não pode validar a funcionalidade do app.
  • O diretório test precisa conter os testes executados na máquina local, por exemplo, testes de unidade. Ao contrário do que foi descrito acima, esses podem ser testes executados em uma JVM local.

Testes de unidade essenciais

Ao seguir a prática recomendada, use testes de unidade nos seguintes casos:

  • Testes de unidade para ViewModels ou apresentadores.
  • Testes de unidade para a camada de dados, especialmente repositórios. A maior parte da camada de dados precisa ser independente de plataforma. Isso permite que os testes duplos substituam módulos de banco de dados e fontes de dados remotas em testes. Consulte o guia sobre como usar testes duplos no Android.
  • Testes de unidade para outras camadas independentes de plataforma, como a camada Domain, para casos de uso e interativos.
  • Testes de unidade para classes de utilitários, como matemática e manipulação de strings.

Testar casos extremos

Os testes de unidade precisam se concentrar nos casos normal e de borda. Casos extremos são cenários incomuns que testadores humanos e testes maiores provavelmente não capturam. Os exemplos incluem:

  • Operações matemáticas usando números negativos, zero e condições de limite.
  • Todos os possíveis erros de conexão de rede.
  • Dados corrompidos, como JSON malformado.
  • Simular armazenamento total ao salvar em um arquivo.
  • Objeto recriado no meio de um processo, como uma atividade quando o dispositivo é girado.

Testes de unidade a serem evitados

Alguns testes de unidade precisam ser evitados devido ao baixo valor deles:

  • Testes que verificam a operação correta do framework ou da biblioteca, não o seu código.
  • Pontos de entrada de framework, como atividades, fragmentos ou serviços, não podem ter lógica de negócios, portanto, o teste de unidade não pode ser uma prioridade. Os testes de unidade para atividades têm pouco valor, porque cobririam principalmente o código do framework e exigem uma configuração mais complexa. Testes de instrumentação, como testes de interface, podem abranger essas classes.

Testes de interface

Existem vários tipos de teste de interface que podem ser usados:

  • Os testes de interface da tela verificam interações importantes do usuário em uma única tela. Eles realizam ações como clicar em botões, digitar formulários e verificar estados visíveis. Uma classe de teste por tela é um bom ponto de partida.
  • Testes de fluxo do usuário ou Testes de navegação, que abrangem os caminhos mais comuns. Esses testes simulam um usuário se movendo por um fluxo de navegação. Eles são testes simples, úteis para verificar falhas no tempo de execução na inicialização.

Outros testes

Há testes mais especializados, como de capturas de tela, testes de desempenho e testes macacos. Você também pode categorizar testes por finalidade, como regressões, acessibilidade e compatibilidade.

Leia mais

Para testar em isolamento, muitas vezes é necessário substituir as dependências do objeto em teste por dependências falsas ou simuladas, chamadas de "Teste duplo" em geral. Continue lendo sobre isso em Como usar testes duplos no Android.

Se você quiser aprender a criar testes de unidade e interface, confira os codelabs Como testar.