La mise à l’échelle des données de test entre pays est habituellement tentée en ajoutant davantage de pays au même générateur. Cela fonctionne un moment puis s’arrête, car les différences entre pays ne sont pas des variations d’un même modèle ; certaines le contredisent.
La voie de sortie consiste à définir ce qui est vrai pour chaque pays et à traiter tout le reste comme une exception explicite. Cet article couvre cette séparation, pourquoi une population générée doit être reproductible, et comment échantillonner les pays afin que la population contienne les cas difficiles plutôt que seulement les faciles.
Qu’est-ce qui appartient à l’ensemble des invariants ?
Un invariant est une propriété qui tient pour chaque pays de l’ensemble, sans réserve. Il mérite ce statut parce qu’il est vrai du modèle de données plutôt que d’un pays particulier.
Les membres typiques sont structurels : chaque pays a un identifiant stable, chaque identifiant correspond à exactement un pays, chaque pays porte un nom d’affichage et un code, et aucun champ n’est obligatoire pour un pays dont le système ne le possède pas. Ces affirmations sont courtes, vérifiables et vraies partout.
Le test pour savoir si quelque chose est véritablement invariant consiste à essayer de trouver un contre-exemple. La plupart des propriétés y survivent, et les rares qui n’y survivent pas sont celles qui seraient sinon imposées à toute la population et produiraient un flot d’échecs qui s’avèrent être la faute du modèle plutôt que des données.
Gardez l’ensemble des invariants petit. Une longue liste d’invariants est généralement une liste d’exceptions déguisée, et il devient impossible de distinguer une vraie régression d’un pays normal se comportant normalement.
À quoi ressemble une liste d’exceptions ?
Une exception est un écart nommé et documenté par rapport à un invariant, limité à des pays spécifiques et portant une raison.
| Élément | Pourquoi il est nécessaire |
|---|---|
| Le ou les pays concernés | Pour que la liste puisse être interrogée plutôt que lue |
| L’invariant dont elle s’écarte | Pour que l’écart soit sans ambiguïté |
| La raison | Pour qu’un lecteur ultérieur puisse juger si elle s’applique encore |
| Ce que le générateur doit faire à la place | Pour que l’écart soit exécutable plutôt qu’indicatif |
La dernière ligne est ce qui sépare une liste d’exceptions d’une liste de plaintes. Une exception qui dit seulement qu’un pays est inhabituel ne peut être appliquée par rien, donc le générateur soit l’ignore, soit traite le pays comme un cas particulier ailleurs, et la liste se désynchronise du code.
Lorsqu’une exception s’applique à un groupe de pays, écrivez-la une fois pour la caractéristique partagée et référencez les pays à partir d’elle. Regrouper par caractéristique plutôt que par liste de codes garde l’affirmation significative lorsqu’un pays est ajouté à l’ensemble ou retiré.
Pourquoi la génération doit-elle être reproductible ?
Parce qu’une population non reproductible ne peut pas être déboguée. Lorsqu’une défaillance apparaît, la première question est de savoir si les données ont changé ou si c’est le code, et un générateur qui produit une population différente à chaque exécution supprime la capacité d’y répondre.
La reproductibilité signifie qu’une entrée donnée produit une sortie identique, y compris l’ordre des enregistrements et les valeurs qu’ils contiennent. Cela exige un point de départ fixe pour les choix aléatoires et une règle qui maintient la séquence de choix stable lorsque l’ensemble de pays grandit, afin d’ajouter un pays ne rebatte pas les données de tous les autres.
La seconde exigence est facile à manquer. Un générateur qui tire des valeurs d’une longue séquence liée au compte total produira une population entièrement différente lorsqu’un pays est ajouté, ce qui détruit la capacité de comparer deux exécutions. Amorcer par pays, ou par pays et par champ, garde chaque entrée stable tout en laissant la population extensible.
Comment les pays doivent-ils être échantillonnés ?
Délibérément, et non uniformément. Une population qui échantillonne chaque pays avec une probabilité égale dépense la majeure partie de son volume au milieu de la distribution et ne contient presque aucun des cas pour lesquels la suite existe.
L’échantillonnage stratifié est la forme pratique : divisez l’ensemble en groupes qui partagent les caractéristiques qui comptent, puis tirez dans chaque groupe plutôt que dans le tout. Les groupes doivent suivre les axes selon lesquels le produit varie réellement — si un champ existe, si les données sont minces ou complètes, si un pays est une dépendance ou une entrée pleinement spécifiée, si la langue diffère du défaut habituel.
Remplissez ensuite les cellules difficiles à dessein plutôt qu’en espérant les atteindre. Une population qui contient un pays sans système de code postal, un petit territoire et un pays dont le nom a changé est plus utile qu’une population plusieurs fois plus grande qui n’en contient aucun.
| Axe | Ce que le faire varier exerce |
|---|---|
| Présence du champ | Chemins de code pour un champ qui ne s’applique pas |
| Épaisseur des données | Entrées incomplètes et états inconnus |
| Type d’entité | Dépendances et codes spéciaux |
| Langue du nom d’affichage | Tri et normalisation |
Échantillonner selon tous les axes à la fois produit une matrice inutilisable, donc choisissez les axes qui comptent pour la suite en question et indiquez ceux qui ont été laissés de côté. Une omission non déclarée se lit comme une couverture.
Pour les développeurs : affirmez les invariants, affirmez les exceptions
Deux couches d’assertion gardent la population honnête. L’une vérifie les invariants sur chaque enregistrement généré, ce qui détecte les cas particuliers accidentels. L’autre vérifie que chaque exception documentée est réellement produite, ce qui détecte une liste d’exceptions qui a dérivé loin du générateur.
La seconde couche est celle que l’on saute, et c’est celle qui détecte la défaillance silencieuse où un pays cesse d’être généré comme la documentation le prétend. Affirmez l’exception par son nom et par la forme attendue, afin qu’une modification du générateur doive s’accompagner d’une modification de la liste.
Alimentez les règles de génération avec les états décrits dans la liste de contrôle de couverture des données pays plutôt que de les traiter comme un rapport, afin qu’un pays dont le champ ne s’applique pas produise un enregistrement qui le dit au lieu d’un enregistrement qui semble inachevé. Pour la couche de codes sous-jacente, le guide des codes ISO de pays et de subdivisions est le contexte pertinent, et le répertoire des pays et régions montre le genre de population à laquelle cette génération est censée ressembler.
La liste d’invariants, la liste d’exceptions et les axes d’échantillonnage de cet article sont une structure illustrative plutôt qu’une spécification. Ils ne décrivent aucune suite de tests réelle, aucun jeu de données réel et aucun ensemble de pays appartenant à une organisation, et ils doivent être adaptés plutôt qu’adoptés.
Prochaines étapes
Écrivez vos invariants sur une page et vos exceptions sur une autre, puis vérifiez lesquels le générateur actuel honore réellement. Une entrée qui a vieilli n’est pas le même problème qu’une entrée qui n’a jamais été complète, et le guide de la fraîcheur des données pays couvre la manière dont les deux devraient être traités différemment.