Testar provedores de conteúdo

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

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

Os provedores de conteúdo permitem que você acesse dados reais do usuário, por isso é importante garantir que você teste o provedor de conteúdo em um ambiente de teste isolado. Isso permite que você só execute em dependências de dados definidas explicitamente no caso de teste. Isso também significa que seus testes não modificam os dados reais do usuário. Para exemplo, evite programar um teste que falhe porque ainda havia dados de um teste anterior. Da mesma forma, o teste deve evitar adicionar ou excluir dados de contato reais em um provedor.

Para testar seu provedor de conteúdo isoladamente, use o ProviderTestCase2 . Essa classe permite usar classes de objetos simulados do Android, como IsolatedContext e MockContentResolver para acessar o arquivo e informações do banco de dados sem afetar os dados reais do usuário.

Programe seu teste de integração como uma classe de teste do JUnit4. Para saber mais sobre como criar classes de teste do JUnit 4 e usar declarações do JUnit 4, consulte Criar um Classe de teste de unidade local.

Para criar um teste de integração para seu provedor de conteúdo, realize estas ações: etapas:

  1. Crie sua classe de teste como uma subclasse de ProviderTestCase2.
  2. Especifique a classe AndroidJUnitRunner que o AndroidX Test oferece. como executor de testes padrão.
  3. Defina o objeto Context da classe ApplicationProvider. Consulte a 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. Esta classe de base estende AndroidTestCase para fornecer o framework de testes JUnit como e métodos específicos do Android para testar permissões de aplicativos. A maior um recurso importante desta classe é a inicialização, que cria a em um ambiente de teste isolado.

Inicialização

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

O construtor cria um MockContentResolver para usar como resolvedor para o teste.

Por fim, o construtor cria uma instância do provedor em teste. Isso é um objeto ContentProvider normal, mas pega todo o ambiente informações do IsolatedContext, então ele se limita a trabalhar em o ambiente de teste isolado. Todos os testes feitos na classe de caso de teste são executados em relação a esse objeto isolado.

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

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 provedor objeto em ProviderTestCase2, sempre teste com um objeto do resolvedor usando o URI apropriado. Isso garante que você está testando o provedor realizando a mesma interação que um aplicativo normal usaria.
  • Testar um provedor público como um contrato: se você quiser que seu provedor seja público e disponível para outros aplicativos, teste-o como um contrato. Veja alguns exemplos de como fazer isso:
    • Teste com constantes que seu provedor expõe publicamente. Por exemplo, procure para constantes que se referem 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árias URIs, cada um se referindo a um aspecto diferente dos dados.
    • Testar URIs inválidos. Seus testes de unidade precisam chamar deliberadamente o provedor com um URI inválido e procurar erros. Um bom design de provedor é oferecer IllegalArgumentException para URIs inválidos.
  • Testar as interações com provedores padrão: a maioria dos provedores oferece seis opções de acesso métodos: query(), insert(), delete(), update(), getType() e onCreate(). Seus testes devem verificar se todos esses métodos funcionam.
  • Teste a lógica de negócios: se o provedor de conteúdo implementa uma lógica de negócios, você deve testá-lo. A lógica de negócios inclui o tratamento de valores inválidos, financeiros ou cálculos aritméticos, eliminação ou combinação de duplicatas.