¿Se puede probar código NFC sin una etiqueta en la mano?
La mitad. Todo lo que convierte bytes en sentido se prueba como código corriente: las tramas que construyes, las respuestas que analizas, los registros que descodificas. Todo lo que pone en juego el campo, una etiqueta que se va, un controlador que rechaza una longitud, una sesión que el sistema termina, solo aparece en un aparato.
Aísla las llamadas de radio
La mitad que se puede probar es la que no toca nunca la radio: construir un comando, analizar una respuesta, decidir qué significan unos bytes de estado, convertir un registro NDEF en algo que tu app entienda. La mitad que no se puede probar cabe en cuatro o cinco llamadas, transceive(), connect(), close() y sus equivalentes de iOS.
Pon entonces esas llamadas detrás de una sola interfaz y deja todo lo demás del lado puro. Esa única decisión es la que marca la diferencia entre un proyecto que tiene pruebas y uno donde cada cambio pide una etiqueta, y no cuesta nada en el momento en que escribes el código.
Lo que se prueba fuera del aparato
Las tramas y los analizadores, primero: los bytes de un SELECT, el recorrido por los bloques TLV de una etiqueta de tipo 2, los dos bytes de estado del final de una respuesta APDU, el campo de longitud de un archivo NDEF. Todos ellos son funciones de bytes a bytes, y sus casos límite, una respuesta truncada, una longitud que rebasa la memoria intermedia, un tipo de registro desconocido, son exactamente para lo que existe una prueba unitaria.
El tratamiento de errores también. Una prueba puede darle a tu código la excepción que lanzaría la plataforma y comprobar qué pasa después: un reintento que empieza por la detección en vez de retomar, una escritura que lee de vuelta antes de decidir, una autenticación que vuelve a empezar. La página de la etiqueta perdida enumera cuáles son esas excepciones.
Lo que solo enseña un aparato
Los límites del teléfono que tienes en la mano: la longitud máxima que puede llevar un comando, si se admiten las APDU extendidas, qué clases de tecnología opcionales existen, todo lo que la página de los límites del controlador lee en ejecución por la misma razón.
Y el comportamiento del campo: una etiqueta que se va a mitad de escritura, una sesión que el sistema termina, un lector que se rinde, las reglas de pantalla bloqueada y pantalla apagada de la emulación de tarjeta, el despacho que hace el sistema operativo antes de que se ejecute tu código. Nada de eso lo simula nada, y por eso las pruebas que importan terminan con un teléfono y una etiqueta en una mano.
Intercambios grabados como juegos de prueba
Graba intercambios reales y reprodúcelos. Un registro de cada comando y de cada respuesta, que la página de ver un intercambio explica cómo producir, se convierte en un juego de prueba: los mismos bytes, reproducidos en la mitad pura de tu código, reproducen el fallo sin la etiqueta que lo causó.
Guarda un juego por familia de etiquetas y por avería. Y guarda las etiquetas mismas, que son una lista más corta de lo que parece: la página del juego de etiquetas la hace.
Preguntas frecuentes
¿Puede un emulador sustituir a una etiqueta?
No. El campo, la temporización y los límites del controlador son la parte que falla, y un emulador no tiene radio con la que fallar.
¿Qué hay que probar unitariamente?
Todo lo que va de los bytes al sentido: tramas, analizadores, bytes de estado, descodificación de registros, y cómo reacciona el código a cada error de la plataforma.
¿Cómo pruebo el tratamiento de errores sin provocar errores?
Dale al código la excepción que lanzaría la plataforma, detrás de la interfaz que envuelve las llamadas de radio, y comprueba qué hace después.
¿Sigo necesitando etiquetas si tengo juegos de prueba?
Sí. Los juegos demuestran el análisis; solo una etiqueta real demuestra el intercambio, la temporización y los límites del teléfono.