Il est facile de développer et de tester un logiciel de localisation uniquement sur des exemples pratiques et bien formés : une adresse propre dans une grande ville, une adresse IP de connexion haut débit résidentielle, un emplacement confortablement éloigné de toute frontière ou limite de fuseau horaire. Chacun de ces tests réussira à coup sûr, et aucun d'eux ne vous apprendra presque rien sur le comportement de votre système dans les situations les plus susceptibles de poser réellement problème une fois confronté aux données réelles, plus désordonnées, de la production.
Une suite de tests réellement utile pour un logiciel de localisation doit inclure délibérément les cas plus difficiles que cette série a abordés un par un : une adresse dans un pays sans numérotation classique des maisons, une requête pour un lieu très proche d'une frontière internationale, un horodatage qui tombe exactement pendant un changement d'heure, une adresse IP connue pour appartenir au pool CGNAT d'un opérateur mobile ou à un fournisseur d'internet par satellite, une coordonnée proche des pôles où les hypothèses fondées sur la longitude commencent à s'effondrer, et un code postal d'un pays dont les données postales sont relativement grossières plutôt que d'un pays aux données de référence exceptionnellement détaillées.
Aucun de ces scénarios n'est exotique ou improbable, inventé uniquement par souci d'exhaustivité. Chacun représente une catégorie réelle et récurrente d'entrées qu'une base d'utilisateurs suffisamment large et véritablement mondiale finira par vous envoyer, de façon prévisible, souvent plus tôt que prévu. Un système qui n'a jamais été testé sur ces cas n'échouera pas bruyamment et de manière évidente, facile à diagnostiquer. Il échouera le plus souvent en silence, en renvoyant un résultat plausible mais subtilement faux qui passe tous les contrôles superficiels et n'apparaît comme un vrai problème que bien plus tard, généralement sous la forme d'un ticket d'assistance déroutant ou d'un indicateur métier inexpliqué qui ne tombe pas juste, et à ce stade il est bien plus difficile de remonter à sa cause réelle.
Construire ce type de jeu de tests relève de la même discipline que celle décrite plus tôt pour mesurer à la fois la précision et la couverture : une collection fixe, volontairement variée et réutilisable d'entrées de test, vérifiée non seulement pour savoir si une réponse plausible revient, mais précisément pour savoir si les champs precision et confidence de cette réponse se comportent de façon sensée et cohérente compte tenu de la difficulté réelle de l'entrée. Un résultat à faible confiance et à précision grossière pour un cas réellement difficile est un résultat correct et honnête, qui doit être considéré comme réussi. Un résultat faux mais affirmé avec assurance, ou une erreur non gérée, est le véritable échec à repérer avant que vos utilisateurs ne le découvrent à votre place.
Notre documentation décrit précisément les champs et le comportement à attendre pour chaque endpoint, ce qui constitue la bonne référence de départ pour construire ce type de jeu de tests délibérément adverse, adapté aux cas limites qui comptent le plus pour votre application et ses utilisateurs.