Testar provedores de conteúdo

Se você estiver implementando um provedor de conteúdo para armazenar e recuperar dados ou torná-los acessíveis a outros apps, teste seu provedor para garantir que ele não se comporte de maneira inesperada. Esta lição descreve como testar provedores de conteúdo públicos e também se aplica a provedores que você mantém privados no seu próprio app.

Criar testes de integração para provedores de conteúdo

Os provedores de conteúdo permitem acessar dados reais do usuário. Portanto, é importante testar o provedor de conteúdo em um ambiente de teste isolado. Essa abordagem permite que você execute apenas nas dependências de dados definidas explicitamente no caso de teste. Isso também significa que os testes não modificam os dados reais do usuário. Por exemplo, evite programar um teste que falhe porque houve dados de um teste anterior. Da mesma forma, seu teste precisa evitar a adição ou exclusão de dados de contato reais em um provedor.

Para testar seu provedor de conteúdo isoladamente, use a classe ProviderTestCase2. Essa classe permite que você use classes de objetos simulados do Android, como IsolatedContext e MockContentResolver, para acessar informações de arquivos e bancos de dados sem afetar os dados reais do usuário.

Crie seu teste de integração como uma classe de teste do JUnit4. Para saber mais sobre a criação de classes de teste do JUnit 4 e o uso de declarações do JUnit 4, consulte Criar uma classe de teste de unidade local.

Para criar um teste de integração para seu provedor de conteúdo, siga estas etapas:

  1. Crie sua classe de teste como uma subclasse de ProviderTestCase2.
  2. Especifique a classe AndroidJUnitRunner que o AndroidX Test oferece como o executor de teste padrão.
  3. Defina o objeto Context da classe ApplicationProvider. Consulte o snippet abaixo para ver um exemplo.

Kotlin


@Throws(Exception::class)
override fun setUp() {
  super.setUp()
  context = ApplicationProvider.getApplicationContext<Context>()
}

Java


@Override
protected void setUp() throws Exception {
  super.setUp();
  setContext(ApplicationProvider.getApplicationContext());
}

Como o ProviderTestCase2 funciona

Teste um provedor com uma subclasse de ProviderTestCase2. Essa classe de base estende o AndroidTestCase (link em inglês) para oferecer o framework de testes do JUnit, bem como métodos específicos do Android para testar permissões de apps. O recurso mais importante dessa classe é a inicialização, que cria o ambiente de teste isolado.

Inicialização

A inicialização é feita no construtor para ProviderTestCase2, que as subclasses chamam nos próprios construtores. O construtor ProviderTestCase2 cria um objeto IsolatedContext que permite operações de arquivo e banco de dados, mas cria stubs de outras interações com o sistema Android. As próprias operações de arquivo e banco de dados ocorrem em um diretório local para o dispositivo ou emulador e tem um prefixo especial.

Em seguida, o construtor cria um MockContentResolver para usar como resolvedor do teste.

Por fim, o construtor cria uma instância do provedor em teste. Esse é um objeto ContentProvider normal, mas usa todas as informações de ambiente do IsolatedContext, o que o limita a trabalhar no ambiente de teste isolado. Todos os testes feitos na classe de caso de teste são executados nesse objeto isolado.

Os testes de integração para provedores de conteúdo são executados da mesma maneira que os testes de unidade de instrumentação.

O que testar

Estas são algumas diretrizes específicas para o teste de provedores de conteúdo.

  • Testar com métodos do resolvedor: mesmo que seja possível instanciar um objeto de provedor no ProviderTestCase2, sempre teste com um objeto do resolvedor usando o URI apropriado. Isso garante que você esteja testando o provedor executando a mesma interação que um aplicativo normal usaria.
  • Testar um provedor público como contrato: se você pretende que seu provedor seja público e disponível para outros aplicativos, teste-o como um contrato. Confira alguns exemplos de como fazer isso:
    • Teste com constantes que seu provedor expõe publicamente. Por exemplo, procure constantes que se refiram a nomes de colunas em uma das tabelas de dados do provedor. Essas constantes devem ser sempre definidas publicamente pelo provedor.
    • Teste de todos os URIs que o provedor oferece. Seu provedor pode oferecer vários URIs, cada um se referindo a um aspecto diferente dos dados.
    • Teste URIs inválidos. Seus testes de unidade precisam chamar deliberadamente o provedor com um URI inválido e procurar erros. Uma boa opção para o provedor é gerar uma IllegalArgumentException para URIs inválidos.
  • Testar as interações com provedores padrão: a maioria dos provedores oferece seis métodos de acesso: query(), insert(), delete(), update(), getType() e onCreate(). Seus testes vão verificar se todos esses métodos funcionam.
  • Testar a lógica de negócios: se o provedor de conteúdo implementar uma lógica de negócios, você precisará testá-la. A lógica de negócios inclui processamento de valores inválidos, cálculos financeiros ou aritméticos, eliminação ou combinação de duplicatas.