Quels tags un développeur doit-il garder pour tester ?
Un de chaque type que le code prétend gérer, puis un de chaque état qu'il doit survivre : vierge, formaté et vide, plein, en lecture seule, protégé par mot de passe, et un tag mort exprès. C'est ce dernier qui prouve que l'étape de vérification sait encore échouer.
Un par type revendiqué
Partez de ce que le code dit gérer. Un autocollant de type 2, une carte de type 4 et un tag de type 5 couvrent les trois familles que la plupart des projets rencontrent, et la page des types de tags dit sur quelle norme chacune repose. Si le déploiement comprend des cartes MIFARE Classic, ajoutez-en une : la classe qui les lit est facultative sur Android, donc un téléphone qui ne l'a pas fait partie du test.
Ajoutez ensuite un second tag du même type et d'une autre puce, avec une autre taille de mémoire. C'est la façon la moins chère d'attraper un numéro de page figé dans le code ou une capacité supposée, la panne dont parle la page des différences entre puces.
Un par état à survivre
Un tag a des états, et le code finit par tous les rencontrer. Vierge et non formaté, ce qu'un tag neuf est parfois, comme l'explique la page du formatage. Formaté et vide, ce qui se lit comme un message de longueur zéro. Plein, pour qu'une écriture qui ne tient pas échoue comme elle le doit, le cas que couvre la page de la taille.
En lecture seule, ce qui refuse l'écriture définitivement, et protégé par mot de passe, ce qui la refuse jusqu'à ce que le code s'authentifie, les deux que sépare la page de la protection. Tous deux existent pour vérifier que vos chemins d'erreur disent la bonne chose plutôt que la même chose.
Le tag qui ne doit jamais se lire
Gardez un tag vraiment mort, et étiquetez-le. La page du tag corrompu en donne la raison : c'est la seule façon de savoir qu'une étape de vérification détecte effectivement un mauvais tag, et cela vaut mieux d'être su avant une série de production qu'après.
Un tag laissé dans un état inconnu est l'inverse : il produit des pannes que personne ne sait attribuer. Si l'état n'est pas écrit dessus, il ne fait pas partie du jeu.
Étiquetés, relevés, gardés
Écrivez l'état sur chaque tag et gardez la liste quelque part où l'équipe peut la lire, la discipline même que la page du relevé demande d'un déploiement. Les mots de passe appartiennent aussi à ce relevé, puisqu'un tag de test protégé dont la clé est oubliée est un tag en lecture seule avec des étapes en plus.
Et rappelez-vous que les tags sont la moitié du jeu. Deux téléphones au moins, l'un sans les classes de technologie facultatives, plus un iPhone, puisqu'un message qu'un analyseur Android accepte peut n'y rien faire, la différence que couvre la page des enregistrements iOS.
Questions fréquentes
Combien de tags faut-il dans un jeu de test ?
Moins qu'il n'y paraît : un par type revendiqué, un par état à survivre, et un tag mort. Une dizaine couvre la plupart des projets.
Pourquoi garder un tag mort ?
Pour prouver que l'étape de vérification sait échouer. Un contrôle qui n'a jamais rien rejeté n'a pas été testé.
Ai-je besoin de tags MIFARE Classic ?
Seulement si votre déploiement en comporte. La classe Android qui les lit est facultative, donc testez aussi sur un téléphone qui ne l'a pas.
Et les téléphones ?
Deux téléphones Android à contrôleurs différents et un iPhone. Le jeu de tags trouve les défauts de contenu, le jeu de téléphones ceux de plateforme.