Datos sintéticos para probar una API de infracciones

Un conjunto de datos de prueba se suele armar como si el problema fuera el volumen: mil patentes parecidas, salidas de un script, para que las pantallas no se vean vacías. Sirve para una demo y casi nunca para encontrar un error: esas mil filas recorren el mismo camino mil veces.

Un conjunto sintético útil se mide de otra forma: por cuántas decisiones distintas obliga a tomar al código que lo consume. Diez casos que representan diez ramas valen más que diez mil variaciones de la misma.

De dónde sale el dato —inventado, derivado de agregados o copiado de patentes de producción— es una decisión previa. Acá suponemos que ya se optó por generar, y queda qué generar.

Un caso es una decisión, no una fila

Antes de escribir el generador, listá qué tiene que resolver la integración: qué hace cuando no hay infracciones, cuando una jurisdicción quedó pendiente, cuando el monto llega sin moneda, cuando aparece una corrección de algo ya guardado, cuando el mismo evento entra dos veces.

Cada una de esas preguntas es un caso: una entrada, un nombre que la describe y una salida esperada. El generador completa el resto; esa lista no se delega.

Un catálogo así crece por motivo y no por tamaño. El sandbox de infracciones provee los escenarios del lado del servidor; el conjunto sintético es lo que el consumidor arma para probarse a sí mismo.

Las restricciones del contrato ya dicen qué generar

No hace falta imaginar los bordes: el esquema publicado los declara. El vocabulario de validación de JSON Schema define restricciones de tipo, presencia, longitud, patrón y conjunto de valores admitidos. Cada una tiene un valor de cada lado.

Si el importe del acta es opcional, hacen falta el caso presente y el ausente, que no es lo mismo que nulo ni que la cadena vacía. Si tiene longitud máxima, el máximo exacto y el máximo más uno. Si es un conjunto cerrado de valores, uno conocido y uno que todavía no existe, porque el productor puede agregarlo mañana.

Derivar los casos del esquema tiene otra ventaja: cuando el contrato cambia, la lista cambia con él y la diferencia queda a la vista. Es la puerta que vigilan los tests de contrato.

Fechas, textos y destinos rompen más que los números

Las fechas concentran errores porque el formato admite más de lo que espera la mayoría de los parsers, y en un acta la fecha decide plazos. RFC 3339 exige un desplazamiento horario explícito, distingue el desplazamiento local desconocido de la hora en UTC y admite el valor 60 en los segundos para representar un segundo intercalar. Un conjunto honesto incluye esas variantes, más medianoche —que en ese perfil sólo se escribe como hora 00— y un cambio de día en hora local.

Los textos libres de un acta —el lugar, la observación— piden lo contrario de un relleno prolijo: tildes, eñes, comillas, una raya, un salto de línea, una cadena en el máximo declarado y otra con caracteres que se parecen a letras latinas sin serlo.

Los destinos tienen reserva propia: el RFC Editor publica dominios de nivel superior y dominios de ejemplo para documentación y pruebas, y usarlos evita que un caso termine escribiéndole por correo o por webhook a un tercero real. Para lo que no tiene reserva —patentes, documentos, números de acta— NIST recomienda que el dato de prueba sea ostensiblemente no natural, para que nadie lo confunda con un dato confidencial verdadero.

Semilla, versión y resultado esperado

Un conjunto que cambia en cada corrida no permite comparar dos ejecuciones: la semilla del generador se fija y se registra. Una prueba aparte, con semillas distintas, verifica que el código no quedó ajustado a una secuencia particular.

El conjunto vive versionado junto al código y cada caso lleva su resultado esperado escrito a mano. Sin él, un caso sólo prueba que el programa no se cae, que es la mitad más barata del problema.

También conviene que tenga dueño y fecha de revisión: los casos que nadie tocó suelen describir un contrato que ya no existe, y una suite verde sobre un contrato viejo da confianza sin fundamento.

Lo que un conjunto verde no demuestra

Que la suite pase significa que el código maneja las formas que alguien imaginó. La realidad produce otras: un campo con espacios al final, un número de acta más largo del previsto, una jurisdicción que devuelve el importe en otra unidad.

Por eso cada incidente de producción debería terminar como un caso nuevo, escrito desde la descripción del problema y no copiando el registro con la patente real que lo causó. NIST advierte que tanto un modelo de alta fidelidad como los datos sintéticos generados a partir de él pueden filtrar información personal potencialmente reidentificable: reproducir con fidelidad el caso real es justo lo que no conviene.

Antes de confiar en un conjunto sintético, revisá tres cosas: que cada caso nombre la decisión que ejercita; que los bordes salgan de las restricciones declaradas y no de la intuición; y que la semilla, la versión del contrato y el resultado esperado estén escritos en alguna parte. Lo que no pasa esos tres chequeos son filas.

Metodología

Alcance: Criterios para construir y mantener el conjunto de datos sintéticos con el que se prueba una integración contra una API de infracciones. No cubre el diseño del entorno de prueba, el dimensionamiento de una prueba de carga ni la elección del origen de los datos.
Unidad de análisis: Un caso — una entrada sintética, la decisión que ejercita y el resultado esperado escrito de antemano.
Cobertura: Restricciones declarativas del vocabulario de validación de JSON Schema 2020-12, formato de fecha y hora de RFC 3339, nombres reservados publicados por el RFC Editor y la orientación de NIST sobre datos de prueba, datos de prueba realistas y datos sintéticos, vigentes al 29 de agosto de 2026.

Limitaciones

Un conjunto sintético ejercita las formas previstas; no anticipa las que ninguna especificación declaró ni las que aparecen cuando una fuente cambia de proveedor.
Un caso verde prueba que el código maneja esa forma, no que la fuente real la produzca ni con qué frecuencia. Para eso hacen falta mediciones de cobertura, no fixtures.
Los bordes derivados del esquema valen mientras el esquema describa lo que el productor devuelve. Un contrato desactualizado genera un conjunto prolijo y equivocado.

Fuentes

JSON Schema Validation Draft 2020-12 — JSON Schema (consultada el 2026-08-29)
RFC 3339 — Date and Time on the Internet — RFC Editor (consultada el 2026-08-29)
Reserved Top Level DNS Names — RFC Editor (consultada el 2026-08-29)
NIST Special Publication 800-188: De-Identifying Government Datasets — National Institute of Standards and Technology (consultada el 2026-08-29)

Preguntas frecuentes

¿Cuántos casos necesita un conjunto de datos sintéticos?

No hay un número. La cuenta que sirve es cuántas decisiones distintas toma la integración: resultado vacío, resultado parcial, corrección posterior, evento repetido, campo ausente, límite de uso. Si dos casos recorren el mismo camino, uno de los dos no está aportando nada.

¿Se puede tomar un caso real y cambiarle los datos para usarlo de plantilla?

Es la vía que más problemas trae. Lo que hace útil a un caso es la decisión que ejercita, y esa se puede escribir desde una descripción en palabras. Copiar el registro arrastra combinaciones, textos libres y adjuntos que nadie revisó; según NIST, los datos de prueba parecidos a los reales dejan de comprometer lo confidencial sólo cuando no se construyeron a partir de información confidencial ni de un modelo basado en ella.

¿Sirve un generador aleatorio sin semilla fija?

Para explorar, sí; para una suite, no. Sin semilla registrada dos corridas no son comparables y una falla intermitente no se puede reproducir. Conviene fijar la semilla del conjunto de referencia y correr aparte, con semillas distintas, una prueba que verifique que el código no fue ajustado a una secuencia particular.

¿El dato de prueba tiene que parecerse a uno real para servir?

Depende de qué se prueba. Un identificador suele necesitar el formato válido para que el validador se ejercite, pero el contenido conviene que sea ostensiblemente artificial: NIST propone nombres del tipo “NOMBRE1 APELLIDO2” justamente para que un dato de prueba no se confunda con uno confidencial. Los valores que sí pueden pasar por reales exigen cuidados aparte.

Datos sintéticos para probar una integración de multas