Un formulaire d’adresse au paiement est l’endroit où chaque problème d’adresse finit par avoir un coût. Un champ qui rejette une saisie légitime, un changement de pays qui écarte discrètement ce qui a été saisi, une validation qui se déclenche alors que l’utilisateur est encore en train de taper — chacun se transforme en commande abandonnée, et aucun n’est visible dans un test unitaire qui vérifie seulement si une chaîne est analysable.
Les cas de test ci-dessous sont écrits contre le comportement du formulaire dans son ensemble plutôt que contre une fonction de validation. Ils couvrent les transitions : changer de pays, revenir à une adresse enregistrée, coller, et terminer sur un téléphone. Les règles de données sous-jacentes dont ils dépendent sont décrites dans validation et normalisation des adresses.
Les formulaires sont ceux que les utilisateurs rencontrent réellement
Avant la liste, une note sur la raison de ces cas précis. Les bugs graves des formulaires de paiement portent rarement sur une seule chaîne invalide. Ils proviennent de l’état : le champ qui a été rempli pour un pays et non vidé pour le suivant, le libellé qui indique encore code ZIP après le changement de pays, le message de validation qui reste à l’écran alors que la valeur a été corrigée.
Écrivez des cas qui parcourent le formulaire comme le ferait une personne, et affirmez ce que l’utilisateur peut voir : si la commande peut être finalisée, ce que disent les libellés des champs, si l’erreur est rattachée au bon champ.
Cas de test pour les champs obligatoires et facultatifs
Commencez par la forme du formulaire lui-même. Dans la plupart des pays, le code postal est obligatoire ; dans certains, il n’existe pas et doit être facultatif. Un champ district ou région est essentiel sur certains marchés et dépourvu de sens sur d’autres. Un formulaire qui marque tous les champs comme obligatoires est inutilisable dans les pays qui n’en ont pas, et un formulaire qui n’en marque aucun comme obligatoire acceptera une adresse vide.
Cas à exécuter : avec seulement les champs obligatoires remplis ; avec tous les champs remplis ; avec les champs facultatifs laissés vides délibérément ; avec les champs facultatifs remplis uniquement d’espaces ; et avec un champ qui existe dans le schéma mais est masqué pour le pays sélectionné. Ce dernier attrape le défaut classique où un champ masqué est quand même validé, de sorte que le formulaire refuse de s’envoyer et n’affiche aucune erreur que l’utilisateur puisse atteindre.
Testez aussi de bout en bout le pays sans code postal. Il doit être possible de finaliser la commande, et la confirmation ne doit pas afficher une ligne de code postal vide.
Que se passe-t-il lorsque le pays change ?
C’est le test à la plus forte valeur de la liste, car le sélecteur de pays change la signification de tous les autres champs. Exécutez-le dans les deux sens : d’un pays avec code postal vers un pays sans, et inversement.
Vérifiez que le code postal saisi sous le premier pays ne persiste pas silencieusement sous le second, que le libellé du champ change pour le terme local, et que toute erreur de validation existante est effacée ou recalculée plutôt que laissée rattachée à un champ dont les règles ont changé. Vérifiez aussi que la liste des subdivisions est remplacée plutôt que filtrée, car une liste filtrée peut laisser une sélection qui n’existe pas dans le nouveau pays.
Un cas connexe : sélectionner le pays en dernier. Certaines personnes remplissent l’adresse d’abord et définissent le pays ensuite. Si la validation s’exécute à chaque frappe, elles verront des erreurs pour un format qui était correct pour un pays qu’elles n’avaient pas encore choisi.
| Situation | Ce que le test doit vérifier |
|---|---|
| Pays changé, puis revenu au précédent | Le code postal saisi sous le premier pays ne persiste pas silencieusement sous le second |
| Libellé de champ | Le libellé change pour le terme local du pays nouvellement sélectionné |
| Erreur de validation existante | Elle est effacée ou recalculée, plutôt que laissée rattachée à un champ dont les règles ont changé |
| Liste des subdivisions | Elle est remplacée plutôt que filtrée, afin qu’aucune sélection obsolète ne subsiste |
Le collage et le remplissage automatique fonctionnent-ils encore ?
Les utilisateurs collent. Ils collent un bloc d’adresse entier dans la première ligne, ils collent un code postal copié depuis un autre onglet, ils collent un numéro de téléphone avec de la ponctuation et un préfixe international. Ils acceptent aussi ce que le navigateur propose de remplir automatiquement.
Testez chacun. Coller une adresse complète dans la ligne de rue doit soit être géré avec élégance, soit laisser le champ modifiable et intact ; cela ne doit pas déclencher une erreur de validation qui bloque l’envoi sans explication visible. Coller un code postal avec des espaces autour doit être accepté après suppression des espaces. Le remplissage automatique doit remplir les champs attendus par l’utilisateur et ne doit pas écraser un pays ou une subdivision déjà choisis.
Testez ensuite le collage qui arrive lentement, caractère par caractère, comme le font certains outils d’assistance. Une validation qui se déclenche à la première frappe et affiche « code postal invalide » alors que la valeur est encore incomplète est un vrai défaut, pas un cas limite.
Tester sur un téléphone et avec une connexion lente
Les mises en page mobiles changent ce que l’utilisateur peut atteindre. Cas à exécuter sur une largeur étroite : le sélecteur de pays s’ouvre et peut être fermé ; le clavier ne recouvre pas le champ en cours de saisie ni le bouton d’envoi ; la liste des subdivisions est consultable ou défilable lorsqu’elle est longue ; et le message d’erreur est visible sans avoir à faire défiler loin du champ.
Ajoutez une connexion lente ou interrompue. Envoyez la commande, interrompez la réponse, renvoyez. Le formulaire ne doit pas créer deux commandes parce que le bouton est resté actif, et il ne doit pas perdre l’adresse saisie lorsque la requête échoue. Le parcours d’adresse enregistrée mérite le même traitement : modifiez une adresse enregistrée, abandonnez la modification, et confirmez que l’originale est intacte.
Pour les développeurs : quoi affirmer et quoi initialiser
Affirmez sur des résultats que l’utilisateur peut observer — l’envoi réussit, le bon libellé est affiché, l’erreur est rattachée au champ qui l’a causée — plutôt que sur des appels de validation internes. Cela garde les tests pertinents lorsque la bibliothèque de validation change.
Initialisez le formulaire à partir d’un jeu de tests qui comprend une adresse propre par marché que vous servez et les incohérences délibérées décrites dans les données d’adresse dans les jeux de tests. Gardez les données d’initialisation déterministes afin qu’un cas qui échoue puisse être reproduit exactement, et générez les échantillons propres plutôt que de les taper à la main, comme le fait le générateur d’adresses.
Enfin, marquez les commandes de test comme telles dans l’environnement lui-même. Une commande de test identique à une vraie finira par être traitée, et une adresse générée pour un test n’est pas une adresse livrable.
Étapes suivantes
Choisissez d’abord le cas du changement de pays — il exerce le plus de code partagé pour le moins de préparation — et ajoutez le parcours sans code postal dans la même session. Exécutez ensuite la liste complète une fois sur une largeur mobile avec le réseau bridé, car cette combinaison trouve plus de défauts de paiement que n’importe quelle quantité de validation de saisie supplémentaire. Pour les règles au niveau des champs derrière ces cas, commencez par la structure d’une adresse américaine.