Android Studio: Tutorial de Testes

Atualizado em 11/08/2017!

Testar bastante o seu app é importantíssimo antes de publicá-lo na Google Play. Mesmo que você não venha a publicá-lo e portanto não passe pelo crivo da análise do Google, é importante que seu app esteja bem testado para que não cause uma experiência ruim aos usuários e consequentemente ninguém o desinstale do smartphone.

No entanto, noto que muitos de meus alunos de cursos de Android e mesmo os leitores de meu livro que me mandam emails não entendem exatamente como testar o seu app corretamente usando as ferramentas do Android Studio. Muitos deles também não sabem que é possível fazer testes bem avançados, simulando diversos acontecimentos no smartphone mesmo se estiverem programando Android no Eclipse ou no NetBeans, via linha de comando.

Portanto, resolvi escrever este tutorial para ajudar com este tópico de como usar as ferramentas do Android Studio E da linha de comando para testar eficientemente os seus apps.

Vamos trabalhar em quatro tópicos nesse post (clique se quiser ir direto para um deles):

1. Usando Extended Controls para testar apps no AVD
2. Como usar linha de comando para manipular o AVD
3. Como fazer testes no seu smartphone
4. Máquinas virtuais concorrentes do Android Simulator
5. Bônus: como testar APIs localhost

Vamos lá!

#1 – Usando Extended Controls para testar apps no AVD

Antes do Android Studio usávamos uma ferramenta chamada DDMS para fazer testes mais elaborados de nossos apps usando AVDs. Basicamente o DDMS simulava diversas características e comportamentos que os dispositivos poderiam enfrentar e consequentemente afetar nossos apps.

No Android Studio as ferramentas do DDMS ainda existem, mas foram integradas na aba Extended Controls do AVD, que fica na última opção à direita do AVD, como mostra a imagem abaixo:

Nessa aba Extended Controls (Controles Estendidos) nós temos acesso à diversos recursos bem interessantes, como um simulador de GPS (mostrado na foto acima), que eu já expliquei melhor nesse post onde ensino como fazer um app de GPS e nesse outro que eu ensino a usar mapas em seu app. Basicamente você pode simular posições GPS específicas ou até mesmo uma rota completa, com direito a fast-forward da rota (para ela ser feita mais rapidamente).

No Extended Controls também temos como mexer na rede do celular, como se tivesse acontecido uma troca de antena, por exemplo (muito comum quando se está usando o celular durante uma viagem de carro). Útil para testar como seu app se comportará quando a Internet oscilar (principalmente apps que usam bancos de dados remotos).

Você pode alterar também o nível de bateria do smartphone, para simular, por exemplo, uma queda de energia com seu app rodando. Muito útil, principalmente para apps multimídia como jogos e players.

Você pode simular estar recebendo uma ligação no meio do uso do app, ou ainda um SMS, com o texto que quiser.

E por fim, pode brincar a vontade com os sensores gravitacionais do AVD simulando que ele está sendo inclinado, por exemplo, para ativar os acelerômetros.

Cada um deles exigiria um post inteiro para exemplificar a criação do app que permitiria seu teste, então fica pra próxima! Além destas opções também existem outras que eu considerei menos importantes, como a simulação do uso de impressão digital, um recurso cada vez mais presente em aparelhos de ponta.

Se você ainda usa alguma ferramenta antiga para desenvolver apps para Android, ela deve usar o DDMS ainda, que muda um pouco em aparência mas que possui as mesmas funcionalidades que o Extended Controls. Além disso, o utilitário de linha de comando que eu vou te ensinar a usar no tópico abaixo é onipresente e nunca falha!

#2 – Como usar linha de comando para manipular o AVD

O Android Studio conecta-se aos AVDs usando um socket chamado ADB, ou Android Debug Bridge, ou Ponte de Depuração Android. Esse ADB permite que nos conectemos ao AVD em uma determinada porta e que a gente envie comandos para ele via telnet.

Na verdade, tudo o que os Extended Controls e o antigo DDMS permitem fazer visualmente acaba gerando comandos que são enviados ao AVD. Você pode usar a própria aba de Terminal existente no Android Studio, que fica lá embaixo na ferramenta, ou então abrir uma janela do console normalmente.

Para se conectar ao AVD é preciso que ele esteja em execução e que você use o seguinte comando no terminal:

Onde localhost é a máquina local (afinal, o AVD também está na máquina local) e 5554 é a porta de conexão com o AVD. O telnet irá pedir autorização para se conectar, mais especificamente você precisa informar o comando auth seguido de um auth token que fica guardado em um arquivo oculto chamado .emulator_console_auth_token, na sua pasta de usuário. No Mac e Linux é muito simples de pegar essa informação via terminal mesmo, com o comando:

Dentro desse arquivo tem apenas o auth token, é só copiar e executar o comando abaixo logo após o telnet:

Ele vai exibir um Ok e vai passar a aguardar comandos para manipulação do AVD via linha de comando. Alguns comandos úteis são:

help <comando>: o mais útil de todos, lista os comandos existentes ou, se você passar o comando, explica o mesmo. Ou seja, se você digitar apenas help no terminal, receberá uma lista como abaixo:

Agora, se digitar apenas ‘help comando’, você terá mais detalhes do mesmo, geralmente a lista de sub-comandos e/ou parâmetros do comando, como no caso do ‘geo’, por exemplo:

E podemos fazer isso para os sub-comandos também, indefinidamente, como neste caso em que estou indo mais à fundo do sub-comando geo fix:

Simples, não?!

geo fix <longitude> <latitude>: altera a coordenada geográfica do AVD, bom para simulação GPS, assim como fiz em meus posts de como fazer um app que use GPS. Atenção: é primeiro longitude e depois latitude e cada um dos valores é um double (use ponto como separador decimal, à moda USA). Se não souber a latitude e longitude dos pontos geográficos que deseja simular, você pode buscar o local na Wikipedia, lá sempre mostra essa informação.

kill: fecha o emulador que você está conectado, útil para quando ele trava tudo. Na verdade faz o mesmo que o comando kill normal do console, mas sem precisar saber o PID do processo, uma vez que você já está conectado no AVD.

network speed <gsm|gprs|edge|etc>: muda a rede de telefonia do celular para simular, principalmente, a queda no tráfego de dados. Muito útil para testar apps que necessitem da Internet por diversos motivos, como se conectar a APIs.

power capacity <porcentagem>: altera a carga da bateria do celular, muito usado principalmente para simular estar acabando a bateria do smartphone. Algumas aplicações de tempo-real, como jogos, necessitam que você faça algum tipo de procedimento nestes casos para que o jogador não perca seus dados se o telefone desligar abruptamente.

sms send <numero> <mensagem>: envia mensagens fakes ao celular. Você pode usar esse comando tanto para testar a chegada de mensagens aleatórias quanto para verificar o recebimento de mensagens do seu próprio sistema. No iPhone, por exemplo, é bem comum quando o iOS envia um SMS para o smartphone ele mesmo já ler quando o SMS chega e tomar a ação apropriada (códigos de confirmação, por exemplo).

avd <start|stop>: serve para inicializar ou interromper um AVD. O start é mais complicado e exige o caminho do arquivo da system image, além de outros parâmetros de configuração (os mesmos configurados visualmente durante a criação do AVD, na área Advanced do assistente). Já o stop é mais tranquilo. Esse comando não tem uma real utilidade para testes em si, mas mais para controle do AVD mesmo.

sensor set <nome> <x>:<y>:<z>: esse comando serve para manipular os sensores do smartphone, principalmente manipula os acelerômetros (sensor acceleration). Primeiro você deve usar ‘sensor status’ para listar os sensores existentes (enabled), e depois chama o ‘sensor set’ passando o nome do sensor e os valores que vai passar pra ele separados por ‘:’.

rotate: muda a orientação de tela em 90 graus (sentido horário). Simples e útil para mudar a orientação via linha de comando.

Existem outros comandos que você pode acessar e estudar facilmente pelo comando help, mas considero os elencados acima como os mais importantes.

#3 – Como fazer testes no seu smartphone

Essa dica é bem simples e ao mesmo tempo muito útil. De longe a melhor dica de performance em testes é usar o seu próprio smartphone para os mesmos. Além de testar a real usabilidade do seu app em um dispositivo de verdade, a execução é muito mais veloz do que no AVD.

Para conseguir isso, você vai ter de seguir alguns passos:

1. para alguns modelos de celular, é importante ter o Google USB Driver instalado como add-on no seu SDK Manager. Dê uma verificada em como você instala add-ons na dica #3 deste tutorial aqui;
2. vá nas Configurações do seu smartphone e depois vá até a área onde diz as informações do aparelho (Sobre ou algo parecido), nesta tela, pressione 7 vezes o Build Number do seu Android (versão de compilação) que vai habilitar as Opções do Desenvolvedor.
3. Nas Opções do Desenvolvedor, habilite a opção Depuração USB e se quiser aproveitar que está aí, marque a opção de GPS Fake que eu não lembro o nome exato agora. 😛
4. Agora volte ao menu de Configurações e entre em Segurança. Lá, marque que você quer permitir apps de Fontes Desconhecidas (os apps que você desenvolve são de uma fonte desconhecida).
5. com o Android Studio fechado, conecte o smartphone no computador usando um cabo USB. Espere a instalação de drivers terminar.
6. Alguns aparelhos, como os Motorola G, exigem a instalação de drivers adicionais. Se for esse o caso, busque na Internet pelo modelo do seu celular seguido das palavras “adb interface” que é o driver de comunicação pra funcionar com o Android Studio. A maioria dos dispositivos Samsung que testei não tinha esse problema.
7. Agora abra o Android Studio e mande executar sua aplicação, deve aparecer o seu smartphone como uma das opções para uso.

Pronto!

#4 – Máquinas virtuais concorrentes do Android Simulator

Muita gente não reclama só da lentidão do Android Studio, mas principalmente da lentidão dos AVDs padrões, usando o Android Simulator. As máquinas virtuais nativas costumam demorar muito tempo para bootar seus SOs, mesmo quando usamos versões antigas como a Gingerbread (2.3) com RAM sobrando pra ela (1024MB). Isso obviamente atrapalha e muito os testes que você precisa fazer de seus apps.

Claro, as dicas de performance que eu dei na dica #8 deste post ajudam bastante, mas caso nenhuma lhe sirva, confere essa lista de opções para você testar seus apps Android com outras máquinas virtuais que não o AVD nativo:

• Genymotion: o mais profissional de todos e que eu uso em alguns casos. Possui performance superior ao Android emulator tradicional e licença free para uso pessoal. Exige que você instale primeiro o VirtualBox na sua máquina.
• BlueStacks: mais usado por gamers para testar APKs, o melhor nesta categoria de apps. Muito já usei em conjunto com FakeGPS para testar Pokemon Go e outros jogos.
• Droid4x: novo e com alguns bugs, mas está crescendo bastante e promete muito para o futuro
• Andyroid: também novo mas com algumas features bem legais como uma sincronização com seu desktop e a possibilidade de usar o seu smartphone real como sendo o “controle” da VM.
• AMIDuOS: funciona só no Windows e é pago, mas já ouvi muitos elogios dele
• YouWave: versão free cheia de ads, não gostei.
• NOX: foco em games e concorrente do BlueStacks
• Xamarin Android Player: mais usado pelo pessoal que usa o referido framework para apps multi-plataforma.
• Manymo: Android emulator online, roda os apps no browser (!!!)
• MEMU: começando agora, possuem muito chão pela frente pra ganharem mercado

Os dois únicos que eu realmente posso opinar, por ter usado bastante, são o GenyMotion, o mais profissional deles, e o BlueStacks, mais usado para testar APKs prontos, principalmente games. No caso do GenyMotion, você cria AVDs assim como no Android Studio e dá o play neles. Quando você for rodar um app no Android Studio para testar, ele vai lhe listar o AVD do GenyMotion que já está ligado. Bem simples.

#5 – Bônus: como testar APIs localhost

Muitos apps Android, principalmente corporativos são apenas “front-end”, apenas uma interface para o acesso a recursos remotos da empresa, como no caso dos bancos, em que os dados da sua conta não estão em seu dispositivo, mas sim nos servidores do banco que são acessados via APIs.

Para realizar testes de apps que consumam APIs (para uso de bancos de dados remotos, principalmente), muitas vezes montamos um webserver local em nossas máquinas para subir uma versão de desenvolvimento da API e não depender da infraestrutura de produção. No entanto, se você tentar chamar uma API dentro de um app Android usando localhost como URL, você notará que não vai funcionar.

Isso porque localhost, no contexto do app, significa o simulador Android, e não o sistema operacional host da sua máquina. Para que localhost aponte para o sistema host da máquina e não o simulador, use 10.0.2.2 que não tem erro, esse IP é redirecionado automaticamente para a máquina host do simulador.

Espero que tenham gostado das dicas e que consigam melhorar os testes dos seus apps!

Se quiserem ainda mais dicas bacanas do Android Studio, confiram este tutorial repleto delas !