Un générateur d’adresses aléatoires ressemble à l’outil le plus simple d’une boîte à outils de test et se comporte comme l’un des plus subtils. Le caractère aléatoire est utile précisément parce qu’il explore des combinaisons que personne n’a pensé à écrire, mais une adresse n’est pas un sac de valeurs indépendantes — c’est un petit réseau de relations, et un aléatoire appliqué séparément à chaque champ détruit ces relations.
Ce guide explique ce qui devrait être aléatoire et ce qui ne devrait jamais l’être, pourquoi une clé reproductible importe plus qu’un grand réservoir de variantes, comment l’export par lots change la forme de votre suite de tests, et quelles erreurs multi-pays reviennent encore et encore. À la fin, vous saurez comment obtenir de la variété sans obtenir de contradictions.
En quoi aléatoire et incohérent sont-ils des problèmes différents ?
Une adresse aléatoire n’est pas la même chose qu’une adresse arbitraire. Le caractère aléatoire réside dans les parties qui ne portent aucune relation : le numéro de rue, le nom du bâtiment, la variante orthographique exacte d’une rue, la séquence des enregistrements dans un lot. Les parties déterministes sont celles qui se contraignent mutuellement, et celles-là doivent être dérivées plutôt que tirées.
Considérez ce qui se passe lorsque chaque champ est tiré indépendamment. La ville est tirée d’une liste, la division administrative d’une autre, le code postal d’une troisième et l’indicatif téléphonique d’une quatrième. Chaque valeur individuelle est valide, et la combinaison ne l’est pas. Quatre valeurs valides produisent un enregistrement invalide, et aucun soin apporté au choix de chaque liste ne l’empêche.
La règle qui résout cela est l’ordre de génération. Choisissez le pays, puis la division de premier niveau, puis la localité, puis dérivez le code postal et l’indicatif téléphonique de cette chaîne. Le caractère aléatoire n’est alors appliqué que là où il ne peut rien contredire, ce qui vous donne de la variété sans la classe de défauts dont souffrent les fixtures fabriquées à la main. L’article sur le générateur d’adresses américaines montre le même principe appliqué à l’intérieur d’un seul pays.
Il existe une façon utile de décrire la différence. Un générateur d’adresses aléatoires ne tire pas douze champs ; il tire un lieu puis le décrit dans le format que ce lieu utilise. Une fois que vous pensez l’enregistrement comme d’abord un endroit et ensuite un ensemble de champs, l’ordre de dérivation cesse d’être un détail technique et devient la manière évidente de construire la chose.
Qu’est-ce qui devrait être aléatoire et qu’est-ce qui devrait être fixe ?
Les valeurs qui devraient varier sont celles qu’un formulaire consomme comme une entrée opaque : les noms de rue à l’intérieur d’un ensemble valide, les numéros de rue, les désignateurs d’unité, les noms d’entreprise, les noms de destinataires, et l’ordre des enregistrements dans un export. Faire varier ces valeurs exerce la mise en page, les limites de longueur et la gestion des caractères de vos champs, ce qui est exactement à quoi sert un générateur aléatoire.
Les valeurs qui devraient être fixes sont celles auxquelles des relations sont attachées. La division doit correspondre à la localité. Le code postal doit correspondre à la division. L’indicatif téléphonique doit correspondre à la région. Le pays doit correspondre au format de tous les autres champs. Aucune de ces valeurs ne peut être tirée indépendamment, et un outil qui propose un mode « entièrement aléatoire » pour l’une d’elles vous propose un défaut.
Il existe une troisième catégorie qui mérite d’être nommée : les valeurs qui devraient être aléatoires dans certains tests et figées dans d’autres. Une date de naissance, par exemple, est utilement aléatoire quand vous traquez des bugs de limite d’âge et nuisible quand vous vérifiez une réponse précise. La décision appartient au test, pas au générateur, ce qui explique pourquoi un générateur qui vous laisse épingler des champs individuels est plus utile qu’un générateur qui n’offre qu’un seul mode aléatoire.
Pourquoi la reproductibilité bat la variété
La même clé et le même pays devraient toujours produire le même enregistrement. Cela ressemble à une limitation du caractère aléatoire et c’est en fait la propriété qui rend les données générées utilisables en test automatisé tout court.
Une assertion compare une valeur observée à une valeur attendue. Si l’entrée change d’une exécution à l’autre, la valeur attendue doit changer avec elle, et le test cesse de vérifier quoi que ce soit sur le comportement pour se mettre à vérifier que le générateur est imprévisible. C’est un test qui ne peut échouer que pour de mauvaises raisons.
La reproductibilité rend aussi les échecs reproductibles. Quand un test échoue sur un enregistrement généré, la première question est de savoir ce que contenait l’enregistrement. Avec une clé, vous pouvez le régénérer exactement et l’inspecter. Sans elle, l’enregistrement est perdu, l’échec est irreproductible, et le rapport de bug devient une anecdote.
C’est la propriété autour de laquelle le générateur d’adresses de ce site est construit : une clé, un pays, un enregistrement stable, et une clé différente chaque fois que vous en voulez un autre. C’est aussi la raison pour laquelle un générateur qui n’offre qu’un bouton de mélange est un outil plus faible qu’il n’y paraît, car un mélange ne peut pas être répété quand une build échoue le mois suivant et que personne ne peut reproduire les données qui l’ont causé.
Le schéma pratique consiste à utiliser une clé stable par fixture. Une clé pour la fixture qui pilote le chemin nominal, une autre pour l’enregistrement doté d’un nom de rue inhabituellement long, une autre encore pour l’enregistrement dont le code postal porte le suffixe étendu. Une clé par fixture vaut mieux qu’une clé par test, car plusieurs tests peuvent partager le même enregistrement et une modification de celui-ci devient un acte délibéré plutôt qu’un accident. L’article sur les données d’adresse dans les fixtures de test décrit comment organiser ces clés pour qu’une suite reste lisible en grandissant.
Comment l’export par lots change votre suite de tests
Une adresse générée unique soutient une vérification manuelle. Un lot de dix mille soutient un type de test entièrement différent, et le format d’export importe plus que le nombre. Un CSV avec une ligne par adresse et des en-têtes de colonnes stables vous permet de piloter une boucle de test dirigée par les données, d’amorcer une base de données de préproduction, et de comparer les comptages et les distributions après une migration.
Deux propriétés rendent un export utilisable. La première est que la ligne d’en-tête nomme les champs comme votre schéma les nomme, de sorte que la correspondance soit explicite plutôt que devinée. La seconde est que chaque ligne porte un marqueur l’identifiant comme donnée générée, soit dans une colonne dédiée, soit dans le nom du fichier et les notes du jeu de données, afin qu’un export égaré ne puisse pas être pris pour un extrait de production.
Les grands lots font aussi remonter des problèmes que les petits dissimulent. Si vous exportez mille adresses pour un pays et que les codes postaux se regroupent en une poignée de valeurs, ou que la liste des villes se répète au bout de vingt lignes, le lot révèle un problème de couverture qu’un échantillon de dix enregistrements n’aurait jamais montré. Les défauts de distribution sont le genre de défaut qui n’apparaît qu’en volume, ce qui est une raison de plus de tester avec du volume.
Qu’est-ce qui casse en premier quand on mélange les pays
La génération multi-pays est là où vivent la plupart des défauts intéressants, car les relations qui tiennent à l’intérieur d’un pays n’existent pas au-delà des frontières. Le premier échec est l’incohérence entre code postal et région, où un code postal valide du mauvais pays est rattaché à une ville valide, ce qu’aucun validateur de champ unique ne détectera jamais.
Le deuxième est le préfixe téléphonique. Un numéro qui porte l’indicatif d’un pays alors que l’adresse se trouve dans un autre est une incohérence qu’une suite de tests soigneuse devrait signaler, et la relation entre préfixe et localité est documentée dans l’article sur la correspondance entre préfixe téléphonique et localité. Le troisième est le problème de l’ensemble de champs : les pays ne partagent pas un schéma, donc un enregistrement généré pour un pays qui n’a pas de code postal produira un champ vide là où votre test attendait cinq chiffres.
Le quatrième échec est plus subtil et vient du formulaire plutôt que des données. Si votre gabarit d’adresse impose un champ d’État pour tous les pays, alors chaque enregistrement généré portera une valeur d’État qui ne signifie rien dans la plupart d’entre eux. L’article sur le format d’adresse international explique comment les ensembles de champs diffèrent selon les pays et pourquoi un gabarit universel est un compromis plutôt qu’une solution.
Il existe un cinquième échec qui n’apparaît que lorsque des enregistrements sont comparés entre eux. Un lot qui mélange les pays ne se triera pas correctement sous un seul classement, car les lettres d’une langue s’ordonnent différemment des lettres d’une autre. Une liste qui paraît brouillée n’est généralement pas brouillée du tout ; elle a été triée avec les mauvaises règles, et le correctif appartient à la couche d’affichage plutôt qu’aux données.
Les adresses aléatoires sont-elles utiles pour les tests de charge
Elles le sont, à une condition : le générateur de charge ne doit pas passer plus de temps à générer que le système n’en passe à servir. Un générateur qui produit un enregistrement bien formé en temps constant convient à une répétition de charge, et un générateur qui valide chaque enregistrement auprès d’un service distant ne convient pas.
Le schéma utile consiste à générer un grand lot hors ligne, à le stocker, et à faire lire le test de charge depuis ce lot plutôt que d’appeler le générateur dans la boucle chaude. Cela rend aussi le test de charge reproductible, car le même lot est rejoué à chaque exécution et la seule variable restante est le système testé.
Le fuzzing est le cas opposé. Là, vous voulez une entrée délibérément malformée, et un générateur qui ne produit que des enregistrements valides ne vous aidera pas. L’approche productive consiste à générer un enregistrement valide puis à le muter de façon contrôlée — tronquer un champ, insérer un caractère hors de l’ensemble attendu, remplacer le code postal par une valeur d’un autre pays — et à enregistrer quelle mutation le système a tolérée. Une mutation qui franchit un contrôle de format mais casse un processus en aval est une trouvaille qui vaut la peine d’être conservée. Gardez le catalogue des mutations sous contrôle de version à côté des réglages du générateur, afin qu’une mutation qui a causé un échec soit rejouée à chaque exécution par la suite.
Ce qu’un enregistrement aléatoire ne peut pas être
Une adresse générée est une donnée synthétique à la structure correcte et aux champs cohérents entre eux. Ce n’est pas un lieu livrable, elle ne correspond à aucun bâtiment, et elle n’est enregistrée au nom d’aucune personne ni organisation. Elle ne sera acceptée par aucun transporteur et ne peut pas servir de preuve de résidence.
Cette frontière vaut la peine d’être énoncée à l’intérieur du jeu de données lui-même, pas seulement dans un document à côté. Une colonne marquant les lignes comme générées, un nom de fichier qui le dit, et une note dans la fixture décrivant à quoi servent les données rendent ensemble un accident bien moins probable, et un accident est la façon dont des données de test finissent là où elles n’auraient jamais dû être.
Le caractère aléatoire ne rend pas non plus les données anonymes si les valeurs ont été prises chez de vraies personnes. Tirer un vrai nom et une vraie adresse d’un enregistrement réel et les mélanger produit un problème d’un autre genre plutôt qu’un problème résolu. Le seul enregistrement de test sûr est celui qui n’a jamais appartenu à personne.
Il reste une propriété à nommer, car il est facile de la perdre lorsqu’on juge un outil sur la variété de sa sortie. Un enregistrement aléatoire reste un enregistrement, et un enregistrement doté d’un but devrait être stockable. Si vous ne pouvez pas écrire l’adresse générée dans un fichier, la valider comme fixture et la régénérer six mois plus tard à partir d’une note, alors le caractère aléatoire vous coûte de la reproductibilité sans rien vous acheter que vous n’auriez pu obtenir d’un échantillon fixe plus large.
Chaque enregistrement produit de cette manière existe pour tester un logiciel, et rien d’autre. Il ne doit pas servir à usurper l’identité de quiconque, à ouvrir ou enregistrer de vrais comptes, à recevoir du courrier réel, à prouver une adresse ou une identité, ni à franchir une étape de vérification.