Mock LocationTeste de localização: simular coordenadas para QA e desenvolvedores
A lógica que depende da localização é uma das mais chatas de testar: o bug se reproduz em um ponto específico de uma cidade, enquanto a equipe está em outra. A simulação de localização transforma essa verificação em um cenário repetível, que você roda da sua mesa quantas vezes precisar. Vamos ver como isso funciona em um aparelho real e onde estão os limites.
Prepare o aparelho
Ative o modo de desenvolvedor, escolha o app de local fictício e dê a ele acesso à localização. Em aparelhos de teste, vale remover logo as restrições de segundo plano — senão o sistema encerra o serviço no meio de um teste longo.
Crie um conjunto de pontos de referência
Salve nos favoritos as coordenadas de que você precisa com frequência: o endereço de um bug report, um ponto no limite da área de entrega, um endereço em outro fuso horário, um ponto no meio da água. Uma lista com nomes de pontos reproduzíveis é a base de testes repetíveis.
Sincronize o conjunto com a equipe
A lista de locais é sincronizada entre o site e os aparelhos pela conta: pontos criados no site aparecem na hora nos celulares de teste, sem copiar coordenadas à mão. Isso economiza muito tempo quando há vários aparelhos.
Rode o cenário e registre o resultado
Ative a simulação no ponto certo e rode o cenário no app em teste. O ponto fica no histórico, então você volta a ele com um toque ao retestar depois de uma correção.
O que é obrigatório testar
Os limites das zonas: um ponto exatamente no limite de uma área de entrega ou de um raio de busca é a fonte clássica de erros de “um a mais”. Mudança de coordenadas com o app aberto: muitos apps pedem a localização uma vez ao abrir e não reagem a mudanças. Ausência de coordenadas: o comportamento com a localização desligada e com a permissão negada.
À parte — dados deliberadamente inválidos: um ponto no meio do oceano, coordenadas no outro hemisfério, lugares sem endereço. O app não pode travar em nenhum desses casos.
Aparelho real ou emulador
O emulador do Android Studio consegue definir coordenadas e reproduzir trajetos, e isso basta no início do desenvolvimento. Mas ele não reproduz o que mais quebra: como um sistema específico se comporta ao encerrar serviços em segundo plano, o funcionamento com sinal fraco, os atrasos reais para obter uma leitura e as diferenças nas políticas de economia de energia dos fabricantes.
Por isso, vale retestar em um aparelho real um cenário que passou no emulador — principalmente se o app em teste usa a localização em segundo plano.
O sinal de fonte fictícia nos testes
O Android marca com um sinal as coordenadas de um provedor de teste. Para QA, isso não é um obstáculo, e sim algo a mais para testar: se o app em teste deve rejeitar coordenadas fictícias, a simulação é justamente a forma de garantir que a verificação funciona de verdade, e não que só foi escrita.
Se o app deve aceitar qualquer coordenada do sistema, confira se ele não as descarta por esse sinal sem querer.
Testar apps com localização em segundo plano
Para apps que acompanham o deslocamento em segundo plano, os testes longos importam: ative a simulação, minimize o app e deixe o aparelho por várias horas. Isso revela problemas que não aparecem em cinco minutos de teste manual — inscrição de atualizações perdida, erros que se acumulam, o sistema parando o serviço.
A notificação permanente na aba serve de indicador: enquanto ela está lá, a simulação está ativa.