Generar un conjunto de datos JSON ficticio

¿Para qué sirven los datos ficticios?

La necesidad aparece en todas las etapas del ciclo de desarrollo. Para una demostración, se necesitan usuarios plausibles, no un Lorem Ipsum truncado. Para pruebas de integración, se busca un juego de datos reproducible pero variado. Para un entorno de preproducción aislado del RGPD, se sustituyen los datos reales por equivalentes ficticios. Para un maquetado UI, hay que poblar tablas con entradas creíbles. El generador de datos ficticios cubre esos casos produciendo registros JSON conformes a un esquema sencillo.

El formato del esquema

El esquema es un objeto JSON en el que cada clave es el nombre del campo producido y el valor es un tipo Faker. Por ejemplo:

{
  "name": "name",
  "email": "email",
  "age": "number 18-65",
  "active": "boolean",
  "registered_on": "date"
}

La herramienta genera después N registros que respetan ese esquema, en la locale elegida (francés o inglés). El resultado es una tabla JSON utilizable directamente como fixture, como cuerpo de una petición de API, o como input de un seeder de base de datos.

Tipos admitidos

• name: nombre completo («Marie Dupont»).
• firstName / lastName: nombre y apellido por separado.
• email: dirección de correo ficticia (utiliza safeEmail de Faker, que produce dominios reservados example.com no alcanzables).
• phone: número de teléfono formateado a la locale.
• address: dirección postal completa.
• number: entero aleatorio entre 0 y 1000 por defecto, o number a-b para un rango personalizado.
• boolean: true o false aleatorio.
• date: fecha en formato ISO 8601 (YYYY-MM-DD).
• uuid: UUID v4.
• text: párrafo corto tipo lorem ipsum (~120 caracteres).
• string: tres palabras aleatorias.
• url: URL ficticia (https://example.org/...).

Cualquier tipo no reconocido se conserva tal cual en el resultado. Es una elección: si pone "role": "admin" en el esquema, cada registro tendrá "role": "admin". Esto permite mezclar valores constantes y campos dinámicos sin cambiar de herramienta.

Elección de la locale

Faker dispone de decenas de locales. La herramienta expone las dos más útiles en un contexto francófono:

• fr_FR: nombres franceses, direcciones francesas, números de teléfono formato francés, frases lorem ipsum en francés aproximado.
• en_US: nombres y direcciones estadounidenses, números de teléfono formato US.

Para coherencia en una demostración en francés, elija fr_FR. Para una prueba de internacionalización, mezcle las dos ejecuciones o aumente el número de registros para disponer de variedad de orígenes.

Casos de uso

• Fixtures de pruebas: generar 50 usuarios, pegarlos en un fichero YAML de AliceBundle o en un seeder. Reproducible cuando se fija un seed Faker, variado si no.
• Maquetados UI: rellenar una tabla React/Vue con datos plausibles. Mucho más expresivo que una tabla vacía o que foo / bar / baz.
• Carga de prueba: generar un payload JSON voluminoso para una prueba de rendimiento (k6, JMeter, Locust).
• Demostraciones comerciales: poblar una instancia de demostración con entradas que se parecen a casos reales pero no corren el riesgo de filtrar información sensible.
• Anonimización: sustituir una exportación de producción por un equivalente ficticio antes de compartirla con un proveedor o usarla en preproducción.

Límites deliberados

Para mantener la sencillez de uso, la herramienta no admite esquemas anidados (un campo que sería a su vez un objeto o una tabla de objetos). Para esas necesidades, conviene escribir un script Faker dedicado, o componer varias llamadas sucesivas. El límite deliberado también evita combinaciones absurdas ("items": "name" con una cardinalidad aleatoria) que harían la herramienta menos previsible.

El número de registros está limitado a 500. Por encima, se espera que un entorno de prueba genere sus fixtures mediante código dedicado (Faker en CLI, Foundry, factory_bot, etc.). La herramienta web es útil hasta unos cientos de registros; por encima, la memoria y el tiempo de respuesta limitan la experiencia.

Reproducibilidad y seguridad

Los valores se producen con un PRNG no determinista: cada ejecución produce datos distintos. Para pruebas que deban ser reproducibles (CI), capture la salida una vez y comítala. Para datos realmente sensibles (anonimización de producción), tenga en cuenta que la generación en un servidor público no es el canal adecuado: prefiera un script local que nunca salga de su equipo.

Preguntas frecuentes

Ejemplo de solicitud

curl -X POST https://cdrn.fr/api/v1/tools/mock-data-generator/execute \
  -H "Content-Type: application/json" \
  -d '{"schema":"{\"name\": \"name\", \"email\": \"email\", \"age\": \"number 18-65\"}","count":5,"locale":"fr_FR"}'

Esquema de entrada

Puntos de acceso

• GET https://cdrn.fr/api/v1/tools - lista todas las herramientas disponibles
• GET https://cdrn.fr/api/v1/tools/mock-data-generator - recupera el esquema de esta herramienta
• POST https://cdrn.fr/api/v1/tools/mock-data-generator/execute - ejecuta esta herramienta con un payload JSON