Le test des champs de sélection de pays tend à s’arrêter à la première assertion que la liste s’affiche. Le contrôle paraît trivial — une liste de pays, un clic, une valeur — et cette apparence est exactement pourquoi ses défauts survivent si longtemps.
Le contrôle est une petite interface posée sur un grand jeu de données, et chaque défaillance intéressante vit dans l’interaction entre les deux. Cet article couvre les formes que le contrôle peut prendre, les différents types de recherche que les gens en attendent, les règles de tri faciles à rater, et le parcours clavier qui est généralement la dernière chose que l’on teste.
Quelles formes le contrôle peut-il prendre ?
Au moins quatre, et elles échouent de manière suffisamment différente pour qu’un test écrit pour l’une ne prouve rien sur les autres. Il y a la liste fermée qui montre chaque option, la liste interrogeable qui filtre au fil de la saisie, le sélecteur hiérarchique qui demande une région avant un pays, et la saisie semi-automatique qui accepte du texte libre et le résout après coup.
La dernière est la plus importante. Dès que le contrôle accepte du texte libre, ce n’est plus un sélecteur ; c’est un problème de correspondance avec une interface par-dessus, et les modes de défaillance passent de « l’option n’a pas été proposée » à « l’option a été proposée et autre chose a été stocké ».
Testez chaque forme que votre produit livre réellement, et testez la transition entre elles. Un contrôle qui passe d’une liste simple à une liste interrogeable au-delà d’un certain nombre d’options ne sera exercé à la frontière que par un test qui atterrit intentionnellement des deux côtés de celle-ci.
Que signifie « rechercher » dans ce contrôle ?
Plusieurs choses différentes, et les utilisateurs ne les distinguent pas lorsqu’ils tapent.
| Ce que l’utilisateur tape | Ce qu’il attend | Ce qui se produit souvent |
|---|---|---|
| Les premières lettres d’un nom | Une liste filtrée, dans l’ordre propre de la liste | Le filtrage fonctionne, l’ordre dérive |
| Un code au lieu d’un nom | Le pays ayant ce code | Les codes ne sont pas du tout recherchés |
| Une forme courte familière | Le pays, une fois | Aucun alias n’existe, la liste est vide |
| Un nom accentué tapé sans accent | Le même pays | La comparaison est octet par octet |
Chaque ligne est une assertion séparée. Rechercher par nom, rechercher par code, rechercher par alias, et rechercher par une orthographe qui ne diffère que par les diacritiques ou la casse sont quatre fonctionnalités, et en livrer une ne prouve rien sur les trois autres.
Se pose aussi la question de ce qui se passe lorsque la recherche ne trouve rien. Une liste vide sans explication se lit comme un contrôle cassé, et le réflexe suivant de l’utilisateur est généralement de retaper la même chose légèrement différemment, ce qui produit la même liste vide.
Pourquoi l’ordre de tri est-il si facile à rater ?
Trier une liste de pays ressemble à une tâche d’alphabétisation jusqu’à ce que la liste quitte l’écriture latine, et même à l’intérieur de celle-ci, la question de savoir quel article ou quelle particule ouvre un nom change la réponse.
Trois conventions s’affrontent. Trier par un nom d’affichage donne l’ordre qu’un lecteur attend pour les noms qu’il peut voir. Trier par un code sous-jacent donne un ordre stable mais dénué de sens pour un utilisateur, ce qui se traduit par une liste qui semble mélangée près du sommet. Trier par un identifiant interne donne un ordre qui change dès que les données sous-jacentes changent, ce qui se traduit par une liste qui se comporte différemment entre les versions sans que personne n’ait touché au code de tri.
Quel que soit votre choix, l’ordre doit être calculé avec les règles de collation de la langue affichée, et non avec une comparaison d’octets par défaut. Une liste correcte dans une langue et visiblement fausse dans une autre est la signature d’une comparaison d’octets portant une étiquette de tri.
Deux autres détails méritent un test explicite. La position d’un pays dont le nom commence par un caractère ayant plusieurs ordonnancements valides, et la position d’un pays dont on parle habituellement avec un article initial. Ce sont tous deux des cas où l’hypothèse d’un implémenteur reste invisible jusqu’à ce que quelqu’un de ce marché lise la liste.
Les options restent-elles cohérentes lorsqu’autre chose change ?
Un contrôle de pays est rarement seul dans un formulaire. Il siège habituellement à côté d’une langue, d’une devise, d’un champ de téléphone ou d’un bloc d’adresse, et ces champs dépendent souvent de la valeur du pays.
Le test qui trouve les défauts ici est un test de recalcul. Changez le pays et vérifiez ce qui arrive à chaque champ dépendant : est-il vidé, recalculé, laissé intact, ou validé contre le nouveau pays ? Chacun de ces comportements est un choix défendable et aucun d’eux ne produit la même expérience utilisateur, donc le choix doit être énoncé plutôt que découvert.
Le cas plus difficile est un champ dépendant qui a été rempli avant que le pays ne soit choisi. Si le pays change ensuite, une valeur qui était valide pour la sélection précédente peut désormais être invalide, et le contrôle doit décider s’il la garde, la signale ou la rejette. Remplir le champ dépendant d’abord puis changer le pays est un test en deux étapes que la plupart des suites n’exécutent jamais.
Pour les développeurs : testez le parcours clavier comme un parcours de premier ordre
L’interaction à la souris couvre les cas évidents et manque ceux qui comptent pour quiconque n’utilise pas de souris. Une passe complète exerce la saisie dans le contrôle pour filtrer, le déplacement dans les résultats sans quitter le champ, et la validation d’un choix au clavier seul.
Le comportement du lecteur d’écran mérite sa propre vérification, car une liste visuellement filtrée et une liste annoncée comme filtrée sont deux expériences différentes. Si le nombre de résultats est affiché visuellement mais non annoncé, l’utilisateur n’a aucun moyen de distinguer un filtre étroit d’un filtre vide.
Ensuite, gardez les données de test honnêtes. Les tables d’alias, les noms d’affichage et les saisies dans une suite de tests doivent être manifestement inventés pour que personne ne prenne plus tard une fixture pour une entrée réelle, et le répertoire des pays et régions est le meilleur endroit où regarder lorsque vous voulez voir comment les noms et les codes sont présentés ensemble. Une page pays unique telle que l’entrée du Brésil est une référence utile pour le niveau de détail qu’un pays porte en dehors du contrôle.
Chaque nom d’option, alias et exemple de saisie dans cet article est inventé à des fins d’illustration. Les entrées de liste utilisées ici sont un matériel de test synthétique, et non une liste de sélection réelle, et aucune fixture montrée ne doit être traitée comme le nom réel d’un pays ni comme une preuve du comportement d’un produit particulier.
Prochaines étapes
Écrivez quatre tests, un par type de recherche, et exécutez-les contre la forme de contrôle que vous livrez. Puis refaites toute la passe souris débranchée. Le guide pays ou langue explique à quelle couche d’un écran le contrôle appartient réellement, et le guide des scénarios d’adresses transfrontalières montre ce qui se passe lorsque la valeur de ce contrôle n’est pas le seul pays de la transaction.