Lässt sich NFC-Code ohne einen Tag in der Hand testen?
Die Hälfte davon. Alles, was aus Bytes Bedeutung macht, testet wie gewöhnlicher Code: die Rahmen, die Sie bauen, die Antworten, die Sie auswerten, die Datensätze, die Sie dekodieren. Alles, was das Feld betrifft, ein Tag, der geht, ein Controller, der eine Länge verweigert, eine Sitzung, die das System beendet, erscheint nur auf einem Gerät.
Eine Trennlinie in den Code ziehen
Die testbare Hälfte ist die, die den Funk nie berührt: einen Befehl bauen, eine Antwort auswerten, entscheiden, was ein Statuswort bedeutet, aus einem NDEF-Datensatz etwas machen, das Ihre Anwendung versteht. Die untestbare Hälfte sind vier oder fünf Aufrufe, transceive(), connect(), close() und ihre Entsprechungen unter iOS.
Stellen Sie diese Aufrufe also hinter eine einzige Schnittstelle und halten Sie alles andere auf der reinen Seite davon. Diese eine Entscheidung macht den Unterschied zwischen einem Vorhaben mit Tests und einem, in dem jede Änderung einen Tag braucht, und sie kostet nichts in dem Augenblick, in dem Sie den Code schreiben.
Was ohne Gerät testet
Rahmen und Auswerter, zuerst: die Bytes eines SELECT, der Lauf durch die TLV-Blöcke eines Type-2-Tags, die zwei Statusbytes am Ende einer APDU-Antwort, das Längenfeld einer NDEF-Datei. Sie alle sind Funktionen von Bytes auf Bytes, und ihre Grenzfälle, eine abgeschnittene Antwort, eine Länge, die den Puffer übersteigt, ein unbekannter Datensatztyp, sind genau das, wofür ein Modultest da ist.
Die Fehlerbehandlung ebenso. Ein Test kann Ihrem Code die Ausnahme übergeben, die die Plattform auslösen würde, und prüfen, was als Nächstes geschieht: ein zweiter Versuch, der bei der Erkennung beginnt statt fortzusetzen, ein Schreibvorgang, der zurückliest, bevor er entscheidet, eine Authentifizierung, die von vorn beginnt. Die Seite zum verlorenen Tag führt auf, welche Ausnahmen das sind.
Was nur ein Gerät zeigt
Die Grenzen des Telefons in der Hand: die größte Länge, die ein Befehl tragen kann, ob erweiterte APDU unterstützt werden, welche wahlfreien Technologieklassen es gibt, was alles die Seite zu den Grenzen des Controllers aus demselben Grund zur Laufzeit liest.
Und das Verhalten des Feldes: ein Tag, der mitten im Schreiben geht, eine Sitzung, die das System beendet, ein Lesegerät, das aufgibt, die Regeln der Kartenemulation zum Sperrbildschirm und zum ausgeschalteten Bildschirm, die Zustellung, die das Betriebssystem vor Ihrem Code erledigt. Nichts davon wird von irgendetwas nachgebildet, weshalb die Tests, auf die es ankommt, mit einem Telefon und einem Tag in einer Hand enden.
Mitgeschnittene Austausche als Testdaten
Schneiden Sie wirkliche Austausche mit und spielen Sie sie erneut ab. Ein Mitschnitt jedes Befehls und jeder Antwort, den die Seite zum Mitschnitt zu erzeugen erklärt, wird zu Testdaten: dieselben Bytes, in die reine Hälfte Ihres Codes gespielt, bilden den Fehler ohne den Tag nach, der ihn verursacht hat.
Halten Sie einen Satz Testdaten je Tag-Familie und je Fehlschlag bereit. Und halten Sie die Tags selbst bereit, was eine kürzere Liste ist, als es klingt: Die Seite zum Satz Tags stellt sie auf.
Häufige Fragen
Kann ein Emulator einen Tag ersetzen?
Nein. Das Feld, das Zeitverhalten und die Grenzen des Controllers sind der Teil, der scheitert, und ein Emulator hat keinen Funk, mit dem er scheitern könnte.
Was sollte mit Modultests geprüft werden?
Alles von Bytes auf Bedeutung: Rahmen, Auswerter, Statuswörter, das Dekodieren von Datensätzen, und wie der Code auf jeden Fehler der Plattform reagiert.
Wie prüfe ich die Fehlerbehandlung, ohne Fehler zu erzeugen?
Übergeben Sie dem Code die Ausnahme, die die Plattform auslösen würde, hinter der Schnittstelle, die die Aufrufe zum Funk umschließt, und prüfen Sie, was er dann tut.
Brauche ich noch Tags, wenn ich Testdaten habe?
Ja. Testdaten beweisen das Auswerten; nur ein wirklicher Tag beweist den Austausch, das Zeitverhalten und die Grenzen des Telefons.