Peut-on tester du code NFC sans tag sous la main ?
La moitié. Tout ce qui transforme des octets en sens se teste comme du code ordinaire : les trames construites, les réponses analysées, les enregistrements décodés. Tout ce qui met en jeu le champ, un tag qui part, un contrôleur qui refuse une longueur, une session que le système termine, ne paraît que sur un appareil.
Isolez les appels radio
La moitié testable est celle qui ne touche jamais la radio : construire une commande, analyser une réponse, décider de ce que veut dire un mot de statut, transformer un enregistrement NDEF en quelque chose que votre application comprend. La moitié non testable tient en quatre ou cinq appels, transceive(), connect(), close() et leurs équivalents iOS.
Placez donc ces appels derrière une seule interface et gardez tout le reste du côté pur. Cette seule décision fait la différence entre un projet qui a des tests et un projet où chaque changement demande un tag, et elle ne coûte rien au moment où vous écrivez le code.
Ce qui se teste hors de l'appareil
Les trames et les analyseurs, d'abord : les octets d'un SELECT, le parcours des blocs TLV d'un tag de type 2, les deux octets de statut à la fin d'une réponse APDU, le champ de longueur d'un fichier NDEF. Ce sont tous des fonctions d'octets vers des octets, et leurs cas limites, une réponse tronquée, une longueur qui dépasse la mémoire tampon, un type d'enregistrement inconnu, sont exactement ce à quoi sert un test unitaire.
Le traitement des erreurs aussi. Un test peut remettre à votre code l'exception que la plateforme lèverait et vérifier ce qui se passe ensuite : une nouvelle tentative qui repart de la détection au lieu de reprendre, une écriture qui relit avant de décider, une authentification qui recommence. La page du tag perdu liste ces exceptions.
Ce que seul un appareil montre
Les limites du téléphone que vous tenez : la longueur maximale qu'une commande peut porter, la prise en charge des APDU étendus, les classes de technologie facultatives présentes, autant de valeurs que la page des limites du contrôleur lit à l'exécution pour la même raison.
Et le comportement du champ : un tag qui part en pleine écriture, une session que le système termine, un lecteur qui renonce, les règles d'écran verrouillé et d'écran éteint de l'émulation de carte, la répartition que le système d'exploitation fait avant que votre code ne s'exécute. Rien de tout cela n'est simulé par quoi que ce soit, et c'est pourquoi les tests qui comptent finissent par un téléphone et un tag dans une main.
Des échanges enregistrés à rejouer
Enregistrez de vrais échanges et rejouez-les. Un journal de chaque commande et de chaque réponse, dont la page du journal explique la production, devient un jeu d'essai : les mêmes octets, rejoués dans la moitié pure de votre code, reproduisent le défaut sans le tag qui l'a causé.
Gardez un jeu par famille de tags et par panne. Et gardez les tags eux-mêmes, ce qui fait une liste plus courte qu'il n'y paraît : la page du jeu de tags la dresse.
Questions fréquentes
Un émulateur peut-il remplacer un tag ?
Non. Le champ, le minutage et les limites du contrôleur sont la part qui échoue, et un émulateur n'a aucune radio avec laquelle échouer.
Que faut-il tester unitairement ?
Tout ce qui va des octets au sens : trames, analyseurs, mots de statut, décodage des enregistrements, et la réaction du code à chaque erreur de plateforme.
Comment tester le traitement des erreurs sans causer d'erreurs ?
Remettez au code l'exception que la plateforme lèverait, derrière l'interface qui enveloppe les appels radio, et vérifiez ce qu'il fait ensuite.
Ai-je encore besoin de tags si j'ai des jeux d'essai ?
Oui. Les jeux d'essai prouvent l'analyse ; seul un vrai tag prouve l'échange, le minutage et les limites du téléphone.