Blog > Automação de Teste com Android - Parte 1

24/jul

Neste artigo iremos aprender a teoria básica de automação para a plataforma Android e seus níveis de automação, que é um ponto importante e de partida para qualquer automação dentro da plataforma Android ou com ferramentas para automação.

Introdução

Hoje sabemos que grande parte dos smartphones vendidos no mundo rodam o sistema operacional Android, além de ter também a maior gama de aplicativos.

Para termos uma ideia já foram ativados (dispositivos com Android em uso) mais de um bilhão de dispositivos e temos mais de um milhão e trezentos mil de apps.

Se removermos o número de apps com foco a games e personalização temos um pouco mais de um milhão de aplicativos para teste.

Só que nem sempre estes aplicativos são testados...

E sobre o processo de aprovação das apps Android?

Todo pessoa que desenvolve um aplicativo Android pode publicá-lo no Google Play. Este aplicativo passa por um processo de aprovação com alguns pontos específicos de qualidade, mas não é o suficiente para remover os bugs da app e termos uma aplicação estável.

Como iremos então garantir uma boa qualidade em apps Android?

Confira abaixo.

Automação Android

A automação Android é dividida em duas partes, segundo o próprio site de desenvolvimento Android:

  • 1.Testes Unitários
  • 2.Testes UI (User Interface – Interface Gráfica)

Fundamentos de Teste

Antes de seguir com a explicação de Teste Unitário e Teste UI vamos conhecer pontos em comum entre os dois níveis de teste.

O Android tem um framework, chamado de Android Testing Framework, como parte da arquitetura de desenvolvimento que nos dá a possibilidade de efetuar testes de diferentes formas na plataforma.

Este framework possui alguns pontos chave:

  • As suítesde teste são baseadas em JUnit (versão 3)
  • As extensões do JUnit para Android que dispõe de métodos auxiliares para a criação de mocks e controle do ciclo de vida de um componente
  • As suítes de teste estão contidas dentro do mesmo projeto em um pacote específico de teste
  • A SDK disponibiliza uma séria de ferramentase extensões disponíveis via Eclipse ADT ou por linha de comando.
  • A SDK também disponibiliza o monkeyrunner que é uma api para dispositivos em Python e também uma ferramenta via linha de comando de stress-test enviando eventos aleatórios na interface gráfica

O diagrama abaixo, retirado da página Testing Fundamentals, explica um pouco do processo de utilização de teste na plataforma:

A caixa de processo (process) é o coração, contendo a aplicação em si (pacote da aplicação) o InstrumentationTestRunner e o Test package (local onde os scripts de teste estão).

O Test package comunica com o InstrumentationTestRunner, classe de apoio contendo todos as facilidades para a instrumentação e acesos aos componentes. Este comunica com o Application package para acessar qualquer tipo de componente para a interação (e teste).

Test Tools e MokeyRunner executam de forma externa sobre a aplicação diretamente no InstrumentationTestRunner.

Para criar testes usamos o conjuto de três itens: JUnit, a Instrumentation e a classe de teste ( Test case classes) que irá acessar o processo. Também podemos utilizar Mocks para este trabalho.

Instrumentação

É um conjunto de métodos que controla os componentes.Não conseguimos controlar o ciclo de vida (onCreate, onResume, onDestroy. Consulte aqui o ciclo de vida) de qualquer componente via API. É através da instrumentação que outros frameworks conseguem “conversar” com os componentes.

Testes Unitários

Sabemos que o Teste Unitário é importante em qualquer tipo de aplicação, e no Android não seria diferente. Há três divisões para testes unitários.

ActivityTesting

Uma Activity é algo focada no usuário, logo focada na interação do usuário com uma tela. Ela é baseada na classe InstrumentationTestCase que habilita a instrumentação nas classes de teste.

Com esta classe podemos:

  • Controlar o ciclo de vida de uma activity
  • Criar Mocks
  • Enviar ações de usuário, como digitação e toques

Há três formas de testar uma activity com as classes:

  • AcitivityInstrumentationTestCase2: habilita o controle de teste funcional dentro de uma activity, geralmente com o foco em múltiplas activities.
  • ActivityUnitTestCase: habilita o controle de uma única activity isoladamente, onde podemos criar mocks e validar seu comportamento no ciclo de vida.
  • SingleLaunchActivityTestCase: hablita o controle de uma única activity mas não habilita a criação de mocks, uma vez que ela mantém o estado da activity e suas chamadas.

Content Provider

Content Provider gerencia o acesso a estruturas de dados na plataforma. Geralmente utilizada na obtenção de dados internos, como Calendário, Notas, Contatos, entre outros.

Neste tipo o foco do teste é garantir o isolamento dos dados para que não ocorra nenhum resultado indesejado ou falso-positivo.

Ele utiliza apenas uma classe, a ProviderTestCase2 para habilitar a injeção dos dados através de mocks.

Service Testing

Services são serviços que executam durante um longo período e não dispõe de interface gráfica.

Através da classe ServiceTestCase poderemos controlar o estado do serviço (se este está executando ou não) e garantido a comunicação com outros serviços ou agentes.

Testes UI

É outro nível de teste que estamos mais acostumados, e não menos importante: o testes da interface gráfica (tela).

Nos itens anteriores aprendemos um pouco sobre testes unitários e como são disponibilizados as classes para ajudar o desenvolvedor a testar o seu código. Mas agora chegou a nossa vez: testarmos com perspectiva de usuário.

Este tipo de teste em Android comumente é chamado de Black Box (caixa preta, que é um dos tipos de teste que conhecemos).

Todos os componentes visíveis na tela para o usuário precisam ser acessíveis, ou seja, precisam ter alguns atributos para que seja possível uma ferramenta encontra-los. Na maioria dos elementos os desenvolvedores devem inserir um conteúdo para o atributo contentDescription (que seria como um ID externo) e no caso de caixas de texto ( EditText) preencher o atributo hint.

A plafaforma Android dispõe de uma ferramenta chamada uiautomatorviewer que consegue analisar os componentes em tela e obter os dados acessíveis (contentDescription ou hint).

Você pode acessá-lo digitando na linha de comando o texto

uiautomatorviwer

ou navegando até a pasta /tools, onde android_sdk é o caminho da pasta sdk do Android.

Os componentes encontrados, posteriormente, servirão de base para escrevermos o código para o script automatizado na interface gráfica do Android.

Considerações

Este artigo teve o intuito de apresentar aspectos de automação na plataforma Android para servir de base a outros artigos relacionados ao desenvolvimento.

É recomendado que você acesse e leia os links contidos neste artigo, que lhe darão uma melhor visão da plataforma e de cada recomendação.

POSTS RELACIONADOS

AGENDA

CURSOS RELACIONADOS