Si può provare del codice NFC senza un tag in mano?
Per metà. Tutto quello che trasforma byte in senso si prova come codice ordinario: le trame costruite, le risposte analizzate, i record decodificati. Tutto quello che mette in gioco il campo, un tag che se ne va, un controller che rifiuta una lunghezza, una sessione che il sistema chiude, compare solo su un apparecchio.
Isola le chiamate radio
La metà che si prova è quella che non tocca mai la radio: costruire un comando, analizzare una risposta, decidere cosa vuol dire un byte di stato, trasformare un record NDEF in qualcosa che la tua applicazione capisce. La metà che non si può provare sta in quattro o cinque chiamate, transceive(), connect(), close() e i loro equivalenti iOS.
Metti quindi quelle chiamate dietro una sola interfaccia e tieni tutto il resto dal lato puro. Quella sola decisione fa la differenza fra un progetto che ha delle prove e un progetto dove ogni cambiamento chiede un tag, e non costa niente nel momento in cui scrivi il codice.
Quello che si prova fuori dall'apparecchio
Le trame e gli analizzatori, per primi: i byte di un SELECT, il percorso attraverso i blocchi TLV di un tag di tipo 2, i due byte di stato alla fine di una risposta APDU, il campo di lunghezza di un file NDEF. Sono tutte funzioni da byte a byte, e i loro casi limite, una risposta troncata, una lunghezza che supera la memoria intermedia, un tipo di record sconosciuto, sono esattamente a cosa serve una prova unitaria.
Anche il trattamento degli errori. Una prova può passare al tuo codice l'eccezione che la piattaforma solleverebbe e verificare cosa succede dopo: un nuovo tentativo che riparte dal rilevamento invece di riprendere, una scrittura che rilegge prima di decidere, un'autenticazione che ricomincia. La pagina del tag perso elenca quali sono quelle eccezioni.
Quello che solo un apparecchio mostra
I limiti del telefono che hai in mano: la lunghezza massima che un comando può portare, se le APDU estese siano sostenute, quali classi di tecnologia facoltative esistano, tutte cose che la pagina dei limiti del controller legge mentre il codice gira per la stessa ragione.
E il comportamento del campo: un tag che se ne va a metà scrittura, una sessione che il sistema chiude, un lettore che rinuncia, le regole di schermo bloccato e schermo spento dell'emulazione di scheda, lo smistamento che il sistema operativo fa prima che il tuo codice giri. Niente di tutto questo è simulato da qualcosa, ed è per questo che le prove che contano finiscono con un telefono e un tag in mano.
Scambi registrati come dati di prova
Registra scambi veri e riproducili. Un registro di ogni comando e di ogni risposta, che la pagina dello scambio spiega come produrre, diventa un dato di prova: gli stessi byte, rimessi nella metà pura del tuo codice, fanno ricomparire il difetto senza il tag che lo ha causato.
Tieni dati di prova per ogni famiglia di tag e per ogni guasto. E tieni i tag stessi, che sono un elenco più corto di quanto sembri: la pagina dei tag da tenere lo fa.
Domande frequenti
Un emulatore può sostituire un tag?
No. Il campo, i tempi e i limiti del controller sono la parte che fallisce, e un emulatore non ha alcuna radio con cui fallire.
Cosa va provato in modo unitario?
Tutto quello che va da byte a senso: trame, analizzatori, byte di stato, decodifica dei record, e come il codice reagisce a ogni errore di piattaforma.
Come provo il trattamento degli errori senza causare errori?
Passa al codice l'eccezione che la piattaforma solleverebbe, dietro l'interfaccia che avvolge le chiamate radio, e verifica cosa fa dopo.
Mi servono ancora dei tag se ho i dati di prova?
Sì. I dati di prova dimostrano l'analisi; solo un tag vero dimostra lo scambio, i tempi e i limiti del telefono.