Choisir les pays pour les données de test est généralement considéré comme une corvée qui suit le travail intéressant. Quelqu’un ouvre la liste de tous les pays dont le système a jamais entendu parler, coche une poignée de noms familiers, puis passe à autre chose. Le choix se fige alors dans un jeu de fixtures, et ce jeu décide discrètement de ce que la suite de tests peut ou ne peut pas détecter.
Cet article se penche sur la décision elle-même. Il expose trois axes pour constituer un ensemble, explique pourquoi un bon ensemble a besoin d’entrées délibérément peu commodes plutôt que simplement populaires, et décrit comment garder l’ensemble sous contrôle de version afin qu’un résultat du mois dernier signifie encore quelque chose aujourd’hui.
Pourquoi l’ensemble de pays mérite-t-il sa propre décision ?
Une seule fixture prouve qu’un enregistrement peut passer. Un ensemble de pays prouve que les règles sont appliquées là où elles doivent l’être. Ce sont deux affirmations différentes, et seule la seconde échoue lorsqu’une règle est liée à la mauvaise région.
Prenez une règle qui suppose qu’un code postal est obligatoire et numérique. Un enregistrement issu d’un pays qui satisfait cette hypothèse vous dit que la règle s’exécute. Il ne vous dit rien des pays où l’hypothèse est fausse, et la défaillance apparaîtra en production plutôt que dans la suite. L’ensemble est l’instrument qui rend cette classe de lacunes visible, et c’est pourquoi il mérite la même revue que le schéma qu’il exerce.
L’ensemble est aussi la documentation la moins coûteuse qu’une équipe puisse laisser derrière elle. Un collègue capable de lire la liste voit quelles conventions la suite prétend connaître, et lesquelles elle a silencieusement accepté d’ignorer.
Trois axes : accessibilité, difficulté des données, valeur limite
La plupart des débats sur une liste de pays portent en réalité sur l’axe qui compte. Les nommer séparément représente l’essentiel du travail.
| Axe | La question qu’il pose | Ce qu’il détecte |
|---|---|---|
| Accessibilité métier | Pouvons-nous réellement desservir ce pays ? | Branches de paiement, livraison, règlement et langue qui ne s’exécutent jamais |
| Difficulté des données | À quel point les données elles-mêmes sont-elles délicates ? | Jeux de caractères, sens d’écriture, longueur des champs et hypothèses d’analyse |
| Valeur limite | Pousse-t-on une limite jusqu’à son extrémité ? | Troncature, débordement de mise en page et erreurs d’un cran |
Un ensemble qui ne suit que le premier axe est une liste de marchés. C’est un point de départ raisonnable et une fin médiocre, car les cas délicats se concentrent exactement là où il n’y a aucun revenu pour les justifier.
Qu’est-ce qui fait un bon échantillon limite ?
Un échantillon limite mérite sa place en étant le cas le plus long, le plus petit ou le moins coopératif pour un champ donné. Le nom de pays qui doit tenir dans la colonne la plus étroite, le nom de division qui doit tenir sur une étiquette imprimée, la ligne d’adresse qui doit tenir dans un cadre fixe — rien de tout cela n’est une curiosité. Ce sont les entrées qui révèlent une largeur fixe.
L’habitude utile consiste à associer chaque limite à l’assertion qu’elle est censée faire échouer. Si un champ est dimensionné pour une adresse confortable et que l’ensemble contient une adresse loin d’être confortable, l’entrée a une raison d’exister. Si chaque entrée est confortablement courte, la mise en page n’est pas testée, quel que soit le nombre d’entrées.
L’ampleur et la profondeur ne se substituent pas l’une à l’autre. Vingt pays similaires exercent vingt fois le même chemin de code ; trois extrêmes bien choisis en exercent trois différents.
Comment gérer les pays où un champ ne s’applique pas ?
Certains pays n’ont aucun système de code postal, et certains n’ont pas de niveau de subdivision qui corresponde au champ qu’un formulaire impose. Ce ne sont pas des données manquantes. C’est la forme des données, et un ensemble qui les omet produit une suite qui traite une adresse correcte comme une adresse invalide.
La distinction à retenir est celle entre une valeur absente parce que le champ ne s’applique pas et une valeur absente parce que personne ne l’a fournie. Seule la seconde est un défaut. Lorsqu’un formulaire rend un tel champ obligatoire partout, l’ensemble de pays est la seule chose qui le révèle : le cas défaillant ne peut même pas être écrit sans un pays où le champ n’existe véritablement pas.
Là où un autre article couvre déjà la forme d’un champ pays par pays, gardez celui-ci restreint et orientez le lecteur. Le guide des formats de codes postaux par pays est la bonne destination pour ce à quoi ressemble un code ; la question ici est seulement de savoir si l’ensemble contient une entrée pour laquelle cette question n’a pas de sens.
De quoi un ensemble par défaut est-il généralement constitué ?
Un ensemble qui survit au contact d’une vraie équipe tend à se stabiliser en trois groupes, et chaque groupe fait un travail que les autres ne peuvent pas faire.
- Le pays d’origine, ou l’endroit où la plupart des hypothèses de l’équipe se sont formées. C’est la référence par rapport à laquelle tout le reste paraît étrange.
- Les principaux marchés, choisis pour les branches qu’ils exercent : livraison, paiement, règlement et contenu.
- Un petit nombre d’extrêmes, choisis parce qu’ils cassent une limite plutôt que parce que quelqu’un y expédie quoi que ce soit.
Le troisième groupe est celui qu’on supprime lorsqu’on allège une suite pour gagner en vitesse, et c’est celui qu’il faut supprimer en dernier. Une suite qui s’exécute vite et rate chaque défaut de troncature n’est pas rapide, elle est aveugle.
Pour les développeurs : traitez l’ensemble comme un actif versionné
La recommandation pratique est d’arrêter de traiter la liste de pays comme de la configuration et de commencer à la traiter comme un actif doté de sa propre identité.
Donnez à l’ensemble un nom et une version, et stockez cet identifiant à côté des fixtures qui en dépendent. Lorsque l’ensemble change, la signification de chaque assertion écrite contre lui change aussi, et sans identifiant il n’existe aucun moyen de distinguer une régression d’une redéfinition. Un résultat stocké n’est interprétable que si vous pouvez retrouver l’ensemble contre lequel il a tourné.
Conservez le raisonnement dans le dépôt, à côté de la liste. Pour chaque entrée, notez l’axe pour lequel elle a été choisie et l’assertion qu’elle est censée soutenir, afin que la prochaine personne à élaguer la liste sache ce qu’elle retire.
Remplissez l’ensemble avec des valeurs construites. Les fixtures ne devraient jamais porter les coordonnées d’une personne réelle, et un ensemble assemblé à partir d’enregistrements réels pose à la fois un problème de confidentialité et un problème de reproductibilité. Le répertoire des pays et régions est un bon endroit pour examiner comment chaque pays et chaque région est décrit avant de valider une entrée, et une page pays unique telle que l’entrée des États-Unis montre à quoi ressemblent les notes d’un pays lorsqu’elles sont rassemblées en un seul endroit.
Une mise en garde couvre tout ce qui précède. Les listes de pays, les noms de régions et les valeurs d’exemple utilisés dans cet article sont des exemples synthétiques conçus pour illustrer une décision de test logiciel. Ils ne décrivent aucune organisation réelle, aucun jeu de données réel et aucune personne réelle, et ils ne conviennent pas comme preuve pour quoi que ce soit en dehors d’un environnement de test.
Prochaines étapes
Prenez le jeu de fixtures que vous utilisez aujourd’hui et marquez chaque entrée avec l’axe pour lequel elle a été choisie. Les entrées qui ne correspondent à aucun axe sont candidates à la suppression, et les axes sans entrée sont les lacunes à combler en premier. Ensuite, écrivez, pour chaque entrée, l’assertion qu’elle protège. Le guide de la couverture des données pays transforme cette liste en quelque chose d’auditable, et le guide de la fraîcheur des données pays traite de ce qui se passe lorsqu’une entrée cesse d’être exacte.