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