Mock LocationPruebas de geolocalización: simular coordenadas para QA y desarrolladores
La lógica basada en la ubicación es de lo más incómodo de probar: el error se reproduce en un punto concreto de una ciudad mientras el equipo está en otra. La simulación de ubicación convierte esa comprobación en un escenario repetible que puedes ejecutar desde tu mesa tantas veces como haga falta. Veamos cómo funciona en un dispositivo real y dónde están sus límites.
Prepara el dispositivo
Activa el modo desarrollador, elige la aplicación de ubicación simulada y dale acceso a la ubicación. En los dispositivos de prueba conviene quitar desde el principio las restricciones en segundo plano; si no, el firmware cerrará el servicio a mitad de una prueba larga.
Crea un conjunto de puntos de referencia
Guarda en favoritos las coordenadas que necesitas a menudo: la dirección de un informe de error, un punto en el límite de una zona de reparto, una dirección en otra zona horaria, un punto en mitad del agua. Una lista con nombres de puntos reproducibles es la base de las pruebas repetibles.
Sincroniza el conjunto con tu equipo
La lista de lugares se sincroniza entre el sitio web y los dispositivos a través de la cuenta: los puntos creados en el sitio web aparecen al momento en los teléfonos de prueba, sin copiar coordenadas a mano. Ahorra mucho tiempo cuando hay varios dispositivos.
Ejecuta el escenario y anota el resultado
Activa la simulación en el punto que necesitas y ejecuta el escenario en la aplicación que pruebas. El punto queda en el historial, así que puedes volver a él con un toque al repetir la prueba tras un arreglo.
Qué hay que comprobar sí o sí
Los bordes de las zonas: un punto justo en el límite de una zona de reparto o de un radio de búsqueda es una fuente clásica de errores por uno. El cambio de coordenadas con la aplicación en marcha: muchas aplicaciones piden la ubicación una vez al iniciarse y no reaccionan a los cambios. La ausencia de coordenadas: el comportamiento con la ubicación desactivada y con el permiso denegado.
Aparte, los datos deliberadamente inválidos: un punto en mitad del océano, coordenadas en el otro hemisferio, lugares sin dirección. La aplicación no debe fallar en ninguno de estos casos.
Un dispositivo real frente a un emulador
El emulador de Android Studio puede fijar coordenadas y reproducir rutas, y eso basta en las primeras fases del desarrollo. Pero no reproduce lo que más a menudo falla: cómo se comporta un firmware concreto al cerrar servicios en segundo plano, el funcionamiento con señal débil, los retrasos reales al obtener una posición y las diferencias en las políticas de ahorro de energía de cada fabricante.
Por eso, un escenario que ha pasado en el emulador conviene repetirlo en un dispositivo real, sobre todo si la aplicación que pruebas usa la ubicación en segundo plano.
La marca de fuente simulada en las pruebas
Android marca las coordenadas de un proveedor de prueba. Para QA no es un obstáculo, sino algo más que probar: si la aplicación debe rechazar las coordenadas simuladas, la simulación es justo la forma de asegurarse de que la comprobación funciona de verdad y no solo está escrita.
Si la aplicación debe aceptar cualquier coordenada del sistema, asegúrate de que no las descarta por esta marca sin querer.
Probar aplicaciones con ubicación en segundo plano
En las aplicaciones que siguen el movimiento en segundo plano importan las pruebas largas: activa la simulación, minimiza la aplicación y deja el dispositivo varias horas. Así salen a la luz problemas que no se ven en cinco minutos de prueba manual: una suscripción a actualizaciones perdida, errores que se acumulan, el firmware deteniendo el servicio.
La notificación permanente del panel sirve de indicador: mientras está ahí, la simulación está activa.