Mock LocationTester la géolocalisation : simuler des coordonnées pour la QA et les développeurs
La logique liée à la position est l’une des plus délicates à tester : le bug se reproduit à un point précis d’une ville alors que l’équipe est dans une autre. La simulation de position transforme cette vérification en un scénario reproductible que l’on lance depuis son bureau autant de fois que nécessaire. Voyons comment cela fonctionne sur un vrai appareil et où sont ses limites.
Préparez l’appareil
Activez le mode développeur, sélectionnez l’application de position fictive et donnez-lui l’accès à la position. Sur les appareils de test, il est judicieux de lever tout de suite les restrictions d’arrière-plan ; sinon, la surcouche tuera le service en plein milieu d’un long test.
Créez un ensemble de points de référence
Enregistrez dans les favoris les coordonnées dont vous avez régulièrement besoin : l’adresse d’un rapport de bug, un point à la limite d’une zone de livraison, une adresse dans un autre fuseau horaire, un point au milieu de l’eau. Une liste nommée de points reproductibles est la base de tests répétables.
Synchronisez l’ensemble avec votre équipe
La liste des lieux se synchronise entre le site et les appareils via le compte : les points créés sur le site apparaissent aussitôt sur les téléphones de test, sans recopier les coordonnées à la main. Cela fait gagner beaucoup de temps quand il y a plusieurs appareils.
Lancez le scénario et notez le résultat
Activez la simulation au bon point et déroulez le scénario dans l’application testée. Le point reste dans l’historique : vous pouvez y revenir en un appui pour revérifier après un correctif.
Ce qu’il faut absolument vérifier
Les limites de zone : un point exactement à la limite d’une zone de livraison ou d’un rayon de recherche est une source classique d’erreurs « à un près ». Le changement de coordonnées pendant que l’application tourne : beaucoup d’applications demandent la position une seule fois au lancement et ne réagissent pas aux changements. L’absence de coordonnées : le comportement avec la localisation désactivée et avec l’autorisation refusée.
À part : les données volontairement invalides, comme un point au milieu de l’océan, des coordonnées dans l’autre hémisphère ou des lieux sans adresse. L’application ne doit planter dans aucun de ces cas.
Un vrai appareil face à un émulateur
L’émulateur d’Android Studio sait définir des coordonnées et rejouer des itinéraires, ce qui suffit au début du développement. Mais il ne reproduit pas ce qui casse le plus souvent : le comportement d’une surcouche précise qui tue les services en arrière-plan, le fonctionnement avec un signal faible, les vrais délais d’obtention d’une position et les différences entre les politiques d’économie d’énergie des fabricants.
Un scénario validé sur l’émulateur mérite donc d’être revérifié sur un vrai appareil, surtout si l’application testée utilise la position en arrière-plan.
L’indicateur de source fictive dans les tests
Android marque les coordonnées issues d’un fournisseur de test d’un indicateur. Pour la QA, ce n’est pas un obstacle mais un sujet de test à part : si l’application testée doit rejeter les coordonnées fictives, la simulation est précisément le moyen de s’assurer que la vérification fonctionne vraiment, et pas seulement qu’elle est écrite.
Si l’application doit accepter toutes les coordonnées du système, assurez-vous qu’elle ne les écarte pas par erreur à cause de cet indicateur.
Tester les applications à localisation en arrière-plan
Pour les applications qui suivent les déplacements en arrière-plan, les longs tests comptent : activez la simulation, réduisez l’application et laissez l’appareil plusieurs heures. Cela révèle des problèmes invisibles en cinq minutes de test manuel : un abonnement aux mises à jour perdu, des erreurs qui s’accumulent, la surcouche qui arrête le service.
La notification permanente dans le volet sert d’indicateur : tant qu’elle est là, la simulation est active.