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:
- Crie sua classe de teste como uma subclasse de
ProviderTestCase2
. - Especifique a classe
AndroidJUnitRunner
que o AndroidX Test oferece como o executor de teste padrão. - Defina o objeto
Context
da classeApplicationProvider
. 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()
eonCreate()
. 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.