Datos y cobertura

Cómo probamos un resultado negativo sin usar datos de una persona

Un resultado vacío sólo es correcto si todas las fuentes esperadas terminaron sin actas. Esa condición puede probarse con fixtures sintéticas, sin buscar una patente real.

Por Marco Ferreiro ·

Tres bandejas vacías verificadas representan un resultado negativo completo y controlado

Encontrar una patente real que hoy no muestre infracciones parece una prueba cómoda para el caso “sin resultados”. Mañana puede aparecer una acta, el portal puede cambiar o esa patente puede terminar copiada en logs y fixtures. La prueba deja de ser estable y usa un dato personal que no hacía falta.

Un resultado negativo se puede demostrar mejor con una ejecución completamente sintética y una definición estricta de completitud.

Qué significa negativo

No significa que el array tenga longitud cero. Significa que todas las fuentes que debían participar terminaron, respondieron de forma válida y declararon cero actas dentro de su alcance. Si una fuente falló o no fue consultada, el resultado global es incompleto.

Esta definición impide que un error de integración se disfrace de buena noticia.

Un identificador que nunca sale del sandbox

La prueba usa un identificador reservado que no respeta el formato de una patente real o pertenece a un rango bloqueado internamente. El adaptador de proveedores rechaza enviarlo fuera del simulador. Así una mala configuración falla antes de tocar un portal.

El tenant, usuario y claves también son sintéticos. Ningún fixture contiene DNI, email personal, acta copiada ni texto de una consulta real.

La fuente simulada responde explícitamente

Cada doble devuelve un sobre con identificador de fuente, versión, hora, estado terminal y lista vacía. No alcanza con null ni con ausencia del campo: esos valores pueden significar que el parser no terminó.

El orquestador espera exactamente el conjunto de fuentes configurado para el escenario. Sólo cuando todas alcanzan el estado terminal correcto calcula el resultado negativo.

Cinco pruebas que deben permanecer separadas

Además del caso feliz se ejecutan:

Ninguno de los primeros cuatro debe devolver “sin multas”. El quinto comprueba que una observación positiva cambia el agregado sin perder la cobertura de las demás.

Qué se verifica en la API

La aserción incluye código HTTP, schema y semántica. La respuesta debe separar total de actas, cantidad de fuentes completas, fuentes con error y estado global. También debe impedir que un campo interno o identificador de ejecución sensible se filtre al cliente.

En la interfaz se prueba el texto accesible. “No encontramos actas en las fuentes consultadas” es distinto de “No pudimos completar la consulta”. El color o un ícono no sustituyen esa diferencia.

Reloj y repetición deterministas

El reloj se congela para que fechas y antigüedad no cambien entre ejecuciones. Se usa una semilla fija para generar los objetos, y el hash del fixture se registra junto con la versión del contrato.

Luego se repite la prueba con orden distinto de llegada. El resultado debe ser el mismo aunque las fuentes completen en otra secuencia. Eso detecta errores donde la primera respuesta vacía cierra prematuramente la consulta.

También se avanza el reloj hasta el vencimiento de una copia cacheada. Antes del límite puede reutilizarse sólo si el contrato lo permite y lo informa; después debe iniciarse una ejecución nueva. La prueba confirma que volver a abrir la pantalla no cambia por sí solo la fecha real de obtención.

Privacidad no es sólo quitar nombres

NIST advierte que desidentificar o sintetizar datos requiere evaluar riesgo y utilidad. Copiar un registro real y borrar la patente puede conservar combinaciones singulares en lugar, fecha, monto o texto. Para esta prueba no necesitamos esa fidelidad: diseñamos desde cero los campos mínimos que ejercitan el contrato.

El entorno y los logs también se limpian después del ensayo. Los identificadores sintéticos pueden conservarse en el repositorio porque son inequívocos y no se relacionan con personas.

La integración externa se prueba aparte

El caso sintético demuestra que nuestra lógica distingue vacío de incompleto. No demuestra que un portal oficial esté disponible ni que su cobertura sea total. Esa evidencia se obtiene con monitoreo autorizado, limitado y sin convertir una matrícula real en fixture permanente.

Probar correctamente un negativo exige más condiciones que devolver cero. Precisamente por eso los datos sintéticos son útiles: permiten controlar cada fuente y repetir el caso sin esperar que la vida real se mantenga quieta.

Metodología

Alcance
Pruebas deterministas del estado negativo de una consulta multi-fuente.
Unidad de análisis
Ejecución sintética con conjunto esperado de fuentes y resultado terminal por fuente.
Cobertura
Caso vacío completo, parcial, timeout, error, fuente omitida y respuesta con actas.

Limitaciones

Fuentes

Preguntas frecuentes

¿Por qué no usar una patente propia sin multas?

Porque el estado puede cambiar, la prueba deja de ser determinista y se incorpora un dato personal innecesario al entorno.

¿Un timeout debe devolver cero multas?

No. Debe quedar como fuente no verificada o error. Cero actas exige una respuesta completa y explícita de la fuente esperada.

¿Los datos sintéticos prueban los portales reales?

Prueban la lógica y el contrato propios. La integración externa se verifica por separado y con límites; no se atribuye al simulador la cobertura del portal.

Notas relacionadas