Les données d’adresse de test sont généralement le dernier jeu de tests que quiconque organise, et le premier à devenir inutile. Elles commencent comme une poignée de chaînes collées dans un script d’initialisation, grossissent d’une ligne à chaque correction de bug, et finissent en quarante échantillons quasi identiques que personne ne comprend et que tout le monde craint de supprimer.
Cet article décrit une manière d’organiser les données pour qu’elles restent lisibles : regroupées par pays et par scénario, reproductibles depuis une origine documentée et clairement marquées comme synthétiques afin qu’aucun lecteur futur ne les confonde avec un dossier client.
Partir des scénarios, pas des pays
L’instinct est d’organiser les jeux de tests par géographie — un échantillon par pays servi. Cela produit une longue liste avec très peu de couverture, car ce qui casse un pipeline d’adresses est rarement le pays lui-même. C’est une forme particulière de données : un code postal manquant, une ligne de rue trop longue, un détail d’unité, une écriture non latine, une région qui ne s’accorde pas avec son code postal.
Organisez d’abord par scénario et notez le pays à l’intérieur de chaque scénario. Un ensemble de départ exploitable ressemble à ceci.
| Scénario | Ce qu’il exerce | Forme d’exemple |
|---|---|---|
| Adresse minimale | Champs obligatoires seulement, sans unité ni district | Rue, ville, division, code postal |
| Adresse complète | Tous les champs facultatifs présents | Ajoute unité, bâtiment, district, deuxième ligne |
| Code postal manquant | Champ facultatif dans certains pays | Un pays dont les adresses ne portent aucun code |
| Code postal à chiffres uniquement | Stockage en texte, zéros initiaux | Un code dont le premier caractère est zéro |
| Code postal lettres et chiffres | Classes de caractères et séparateurs | Un code aux lettres entrelacées |
| Ligne de rue trop longue | Limites de longueur et troncature | Un nom long plus un détail d’unité |
| Écriture non latine | Jeu de caractères et rendu | Un nom dans un système d’écriture non latin |
| Région incohérente | Vérifications relationnelles | Une région qui ne peut pas héberger ce code postal |
Cet ensemble est petit, et il couvre plus de modes de défaillance qu’un échantillon provenant de tous les quatre-vingts pays et quelques. Le pays qui ne teste rien est celui que tout le monde prend déjà en charge.
Pourquoi les jeux de tests d’adresses doivent-ils être reproductibles ?
Un jeu de tests d’adresses qui ne peut pas être régénéré est un jeu de tests en lequel personne n’a confiance. Si les données ont été copiées de quelque part une fois et que la source a disparu, alors lorsqu’un test échoue, vous ne pouvez pas dire si l’échec est une régression dans votre code ou un changement dans une valeur qui se trouvait là par hasard.
La reproductibilité signifie que la même entrée produit la même sortie, sur n’importe quelle machine, à n’importe quel moment. Deux moyens d’y parvenir. Soit les valeurs sont dérivées de manière déterministe d’un identifiant — la même graine, la même adresse, à chaque exécution — soit les valeurs sont versionnées sous forme de fichiers et jamais modifiées à la main. Ce qui ne fonctionne pas, c’est un générateur qui renvoie un échantillon différent à chaque appel et l’écrit dans le jeu de tests, car alors deux ingénieurs exécutant le même test comparent des données différentes.
La génération déterministe a un second avantage dans les environnements de préproduction. Un enregistrement chargé deux fois porte la même adresse, de sorte qu’une réexécution ne crée pas de doublons qui ne diffèrent que par leurs champs d’adresse, et qu’une capture d’écran de la semaine dernière correspond encore à l’enregistrement que vous consultez aujourd’hui.
Pourquoi les vraies adresses de clients n’ont jamais leur place ici
Copier des adresses de production dans un environnement de test ou de préproduction est l’erreur de protection des données la plus courante dans ce domaine, et il est facile de comprendre pourquoi on la commet : les données sont réalistes, elles sont déjà là, et personne n’a à réfléchir à la couverture.
Une adresse est une donnée personnelle. Elle identifie une personne, ou un très petit groupe de personnes, et combinée à un nom, à un historique de commandes ou à un identifiant de compte, elle suffit à rendre quelqu’un localisable. Une base de données de préproduction construite en copiant la production hérite de tout cela, généralement avec des contrôles d’accès plus faibles, plus de copies sur plus d’ordinateurs portables et une durée de conservation plus longue que prévu. Les règles diffèrent selon la juridiction et le contrat, et cet article ne constitue pas un avis juridique, mais la pratique technique ne fait aucun doute : ne déplacez pas de vraies données d’adresse vers un environnement hors production. Le tableau d’ensemble, y compris la conservation et le masquage, est traité dans la confidentialité des données d’adresse.
Les données synthétiques suppriment le dilemme. Elles sont réalistes par la forme, elles ne sont l’adresse de personne, et elles peuvent être publiées, partagées, versionnées et régénérées librement.
Comment garder des données synthétiques honnêtes ?
Les données synthétiques se dégradent. Quelqu’un ajoute un champ, quelqu’un d’autre modifie à la main une valeur pour reproduire un bug, et en quelques mois le jeu de tests ne correspond plus au schéma qu’il est censé tester.
Trois habitudes ralentissent cette dégradation. Marquez les données comme synthétiques dans le jeu de données lui-même, pas seulement dans un commentaire, afin qu’une ligne porte son propre statut partout où elle voyage. Conservez une origine documentée pour l’ensemble — un seul appel au générateur ou un seul fichier versionné — plutôt qu’une provenance par enregistrement que personne ne met à jour. Et redérivez les jeux de tests lorsque le schéma change plutôt que de rafistoler des lignes individuelles, afin que l’ensemble reste cohérent en interne.
Il aide aussi de rendre la nature synthétique visible là où cela compte. Un nom de destinataire ou un marqueur dans le bloc d’adresse qui n’est manifestement pas réel empêche qu’une capture d’écran de préproduction soit prise pour un vrai enregistrement, et empêche qu’une adresse de test soit utilisée pour un envoi réel par quelqu’un qui l’a trouvée dans un journal. L’ensemble dans son entier est synthétique : conçu pour tester des logiciels, rattaché à aucun itinéraire de distribution réel, et muet sur la résidence de quiconque.
Pour les développeurs : forme, isolation et revue
Gardez les jeux de tests dans le dépôt sous forme de données, pas sous forme de code qui construit des données en ligne. Des valeurs dans un fichier sont comparables, révisables et interrogeables ; des valeurs construites par une chaîne d’appels à l’intérieur d’un utilitaire de test ne le sont pas, et lorsqu’un jeu de tests change, personne ne le voit en revue.
Donnez à chaque champ le type qu’utilise le schéma de production, y compris le type texte pour les codes postaux. Un jeu de tests qui stocke un code postal sous forme de nombre masquera le bug de zéro initial qu’il était censé attraper, et le test réussira pour la mauvaise raison. Les jeux de tests doivent être aussi stricts que la production, jamais plus indulgents.
Isolez les données par environnement et soyez explicite sur l’ensemble qui s’exécute où. Les tests unitaires veulent de minuscules échantillons déterministes ; les tests d’intégration veulent la matrice de scénarios ci-dessus ; les données d’initialisation de préproduction veulent du volume, généré plutôt que copié. Les trois ensembles ont des durées de vie différentes, et les fusionner est ce qui rend un script d’initialisation impossible à modifier en sécurité.
Enfin, révisez les modifications de jeux de tests comme du code. Une modification d’une ligne dans un jeu de tests peut silencieusement transformer un test qui échoue en un test qui réussit, et c’est exactement le genre de changement qui arrive dans un gros diff sans explication.
Étapes suivantes
Écrivez la matrice de scénarios de votre propre produit avant d’ajouter un nouvel échantillon de pays, et supprimez les jeux de tests qui ne testent rien. Générez ensuite l’ensemble synthétique en un seul passage dans le générateur d’adresses, versionnez les valeurs et enregistrez les paramètres qui les ont produites. Si vos jeux de tests comportent aussi des numéros de téléphone, les règles de cohérence de l’appariement entre préfixes téléphoniques et localité méritent d’être appliquées en même temps. Pour la différence entre reformatage et véritable vérification, voir validation et normalisation des adresses.