Generador de Datos Falsos
Se genera en tu navegador y nunca se transmite. Los nombres son ficticios, los teléfonos usan el rango reservado 555-01xx y las direcciones IP proceden de los bloques de documentación del RFC 5737: nada de esto pertenece a una persona o host real.
Nada de lo que escribes aquí se almacena, registra ni comparte.
Define los campos que necesitas y genera hasta 1.000 filas de datos falsos realistas en JSON, CSV o sentencias INSERT de SQL. Todo se genera en tu navegador, asi que no se sube nada y no se usa ningun dato personal real.
Cómo usarlo
- Nombra cada campo y elige que tipo de valor debe contener.
- Elige cuantas filas necesitas y si quieres JSON, CSV o SQL.
- Pulsa Generar y copia el resultado.
Por qué importan los rangos reservados
Todos los valores generados salen de rangos reservados formalmente para la ficción, y no es por puntillismo: es la diferencia entre un conjunto de pruebas que es seguro ejecutar y uno que no lo es.
Los teléfonos usan +1-555-01xx, el bloque de cien números que el Plan de Numeración de Norteamérica reserva para uso ficticio; el resto del 555 se liberó para asignaciones reales hace años, así que la vieja costumbre de usar cualquier número 555 ya no es segura. Los correos y las URL usan example.com, example.org y example.net, reservados por la RFC 2606 y con la garantía de que nadie los registrará nunca. Las direcciones IP salen de los bloques de documentación de la RFC 5737, que no se enrutan.
El fallo que esto evita está bien documentado y sigue ocurriendo: una prueba con fixtures llenos de direcciones verosímiles envía correos reales a personas reales, una prueba de carga marca números de teléfono reales o una base de datos de staging con datos de semilla acaba conectada a un relé SMTP de producción. Unos fixtures que no pueden llegar a nadie lo resuelven de forma estructural, no por procedimiento.
Fixtures que de verdad encuentran errores
Los datos uniformemente razonables son cómodos y poco útiles. Todos los nombres de seis a diez letras, todas las cadenas en ASCII, todos los campos opcionales rellenos: unas pruebas construidas así pasan y no dicen nada de lo que ocurre en producción.
Los casos que conviene añadir a mano una vez tienes una base: cadenas vacías y nulls en cada columna que admita null, porque siguen caminos distintos. Nombres con apóstrofos, guiones, tildes, eñes y escrituras no latinas, que es donde afloran los errores de codificación y el escapado ingenuo. Un valor con exactamente la longitud de la columna y otro con un carácter más. Fechas límite: fin de mes, fin de año, 29 de febrero, el día del cambio de horario de verano. Valores duplicados en campos que dabas por únicos. Un único registro muy grande entre registros pequeños.
Los datos generados te dan volumen y forma rápidamente, que es lo que necesitas para paginación, ordenación, comportamiento de índices y renderizado. Las filas incómodas son lo que necesitas para la corrección, y normalmente merece la pena escribirlas a propósito en lugar de esperar a que un generador las produzca.
Los tres formatos de salida
JSON es el formato adecuado cuando el destino es código: un fixture de API, un servidor simulado, un script de semilla, un archivo que una prueba lee al arrancar. Los registros salen como un array de objetos con los nombres de tus campos como claves.
CSV encaja en las vías de importación masiva - una hoja de cálculo, un COPY en la base de datos, un formulario de subida de un panel de administración - y es la opción correcta cuando quieres revisar los datos como tabla antes de cargarlos. En el otro extremo se aplican las advertencias habituales del CSV: un consumidor que adivina tipos tomará sus propias decisiones sobre cualquier cosa que parezca numérica.
SQL genera sentencias INSERT simples para el nombre de tabla que indiques, una por fila, que se ejecutan en cualquier cliente sin driver ni script. Las cadenas se escapan duplicando las comillas, los números se escriben tal cual, los booleanos como TRUE y FALSE, y los identificadores que no son palabras simples van entre comillas dobles. Para una semilla grande conviene envolver la salida en una transacción, ya que mil sentencias individuales fuera de una son lentas en la mayoría de motores.
No anonimices datos de producción en su lugar
El atajo tentador cuando necesitas datos de prueba realistas es copiar la base de datos de producción y borrar los campos personales. Merece la pena entender por qué esto sale mal una y otra vez.
Eliminar nombres y correos no anonimiza un conjunto de datos. Las combinaciones de atributos corrientes - código postal, fecha de nacimiento, sexo; o unas cuantas marcas de tiempo y ubicaciones - suelen ser únicas para una persona, y la investigación sobre la reidentificación de datos supuestamente anónimos es amplia y coherente. Mientras tanto, la copia depurada es un conjunto de datos de producción con total fidelidad que vive en un entorno con controles de acceso más débiles, acceso más amplio para desarrolladores y copias de seguridad de las que nadie lleva la cuenta.
Generar a partir del esquema evita toda esa categoría de problemas. Los datos tienen la forma correcta y ninguna procedencia, así que una fuga desde staging es un incidente sin contenido. Cuando de verdad necesitas distribuciones parecidas a las de producción, lo defendible es modelar las estadísticas y generar a partir del modelo, no transformar los registros.
Diseñar un conjunto de datos en lugar de rellenar columnas
Los datos de prueba realistas no son datos aleatorios; son datos cuya forma coincide con la de producción. Las tablas reales están sesgadas: la mayoría de los clientes tiene un pedido y un puñado tiene miles, la mayoría de los documentos es corta y uno es enorme, la mayoría de las sesiones dura un minuto y unas pocas duran un día. Un fixture donde cada cliente tiene exactamente tres pedidos nunca sacará a la luz la consulta que se cae con el cliente que tiene cuatro mil.
El volumen importa por la misma razón. La paginación, el ordenamiento y el comportamiento de los índices son invisibles con cincuenta filas y evidentes con cincuenta mil, y una página que se dibuja al instante con una lista corta puede tardar segundos con una realista. Generar un orden de magnitud más de lo que esperas es la prueba de carga más barata que existe.
La integridad referencial es la tercera pieza. Los pedidos necesitan clientes que existan, los comentarios necesitan publicaciones, y los registros hijos necesitan padres con fechas verosímiles: un pedido hecho antes de que el cliente se registrara es una fila que confundirá a todos los informes que se construyan sobre ella más adelante.
Semillas, determinismo y repetibilidad
Una prueba que genera datos aleatorios nuevos en cada ejecución falla de forma intermitente, y un fallo intermitente es peor que uno constante porque nadie puede reproducirlo. La disciplina habitual es una semilla fija: la misma secuencia en cada ejecución, de modo que un fallo sea repetible y un bisect tenga sentido.
Eso choca con querer datos variados, y el punto medio en el que se asientan la mayoría de los equipos es un generador con semilla cuya semilla se imprime en la salida de la prueba. Las ejecuciones son reproducibles cuando lo necesitas y variadas con el tiempo, y cuando una combinación rara rompe algo, la semilla del log la reconstruye exactamente.
Los scripts de carga inicial también deberían ser idempotentes. Ejecutar la carga dos veces debería dejar la base de datos en el mismo estado en lugar de duplicar cada tabla, lo que en la práctica significa vaciar primero o hacer upsert sobre una clave natural. Quien tenga que borrar la base de datos para volver a cargarla evitará volver a cargarla, y los datos locales desactualizados son una categoría de error en sí misma.
Fixtures, factories y snapshots
Dominan tres patrones, y resuelven problemas distintos. Los fixtures son archivos estáticos que se cargan antes de una prueba: predecibles, fáciles de leer e incómodos de mantener, porque un cambio de esquema implica editar todos los archivos. Las factories construyen objetos en código con valores por defecto razonables y sobrescrituras por prueba, así que una prueba declara solo los campos que le interesan: el enfoque más extendido en la mayoría de las suites modernas.
Los snapshots capturan la salida de una función y afirman que no cambia. Son excelentes para el renderizado y la serialización, y peligrosos cuando nadie lee el diff: un snapshot actualizado que consagra un error es un modo de fallo común en suites grandes.
Los datos generados del tipo que produce esta herramienta están por debajo de los tres. Rellenan el grueso - las miles de filas que hacen que el rendimiento y la paginación sean realistas - mientras que los registros concretos y difíciles se escriben a mano, porque el caso que rompió producción el mes pasado merece declararse de forma explícita en vez de esperar que un generador lo reproduzca.
Por qué copiar datos de producción sigue saliendo mal
Tomar un volcado de producción y borrar los nombres parece la vía más rápida hacia datos realistas, y falla por razones estructurales más que de procedimiento. Quitar los identificadores directos no anonimiza un conjunto de datos: combinaciones de atributos corrientes como código postal, fecha de nacimiento y sexo son con frecuencia únicas para una sola persona, y la investigación sobre la reidentificación de conjuntos de datos supuestamente anónimos es amplia y consistente.
El problema operativo es distinto e igual de serio. La copia depurada es un conjunto de datos de producción con fidelidad completa viviendo en un entorno con controles de acceso más débiles, acceso más amplio de los desarrolladores y copias de seguridad que nadie rastrea. Bajo el GDPR, los datos seudonimizados siguen siendo datos personales y siguen dentro del ámbito de aplicación; esto es una observación general y no asesoramiento legal, y los detalles dependen de tu jurisdicción y de tu responsable de protección de datos.
Generar a partir del esquema esquiva la categoría entera. Los datos tienen la forma correcta y ninguna procedencia, así que una filtración desde staging es un incidente sobre nada. Donde hacen falta de verdad distribuciones parecidas a las de producción, la versión defendible es modelar las estadísticas y generar a partir del modelo, en lugar de transformar registros reales.
Llevar la salida adonde tiene que ir
Para una base de datos, la salida SQL se ejecuta en cualquier cliente sin necesidad de un driver, y envolverla en una transacción hace que una carga grande sea muchísimo más rápida: mil sentencias sueltas fuera de una transacción son lentas en casi cualquier motor. En el caso concreto de PostgreSQL, un COPY desde un CSV supera con creces a las sentencias INSERT en cuanto el número de filas pasa de unos pocos miles.
Para una aplicación, JSON suele ser el destino adecuado: un archivo de fixture que la prueba carga al arrancar, una respuesta para un servidor de mocks, o un script de carga inicial que consume el ORM. Los nombres de los campos salen exactamente como los configuraste, así que hacerlos coincidir con los nombres de las propiedades del modelo ahorra un paso de mapeo.
CSV es el formato para los caminos donde interviene una persona: una hoja de cálculo para revisar a ojo antes de importar, un formulario administrativo de carga, una herramienta de importación masiva. Eso sí, recuerda las advertencias de siempre sobre CSV al otro extremo: un consumidor que adivina los tipos tomará sus propias decisiones sobre todo lo que parezca numérico, y los ceros a la izquierda en los números de referencia son la víctima habitual.
Preguntas frecuentes
- Es seguro subir los datos generados a un repositorio?
- Si, y es intencionado. Los nombres salen de una lista ficticia, los telefonos usan el rango +1-555-01xx que el plan de numeracion norteamericano reserva para ficcion, los correos y las URL usan la familia example.com reservada por el RFC 2606, y las direcciones IP proceden de los bloques de documentacion del RFC 5737. Nada de lo generado aqui apunta a un host real ni llama a una persona real.
- Por que no pedirle los datos de prueba a una IA?
- Para tres filas, pideselos. Para 500 filas con un esquema fijo necesitas repetibilidad y nombres de columna exactos, que es lo que da un generador y no un chat. Ademas es mas rapido cambiar el tipo de un campo y volver a generar que reescribir el prompt, y aqui la salida nunca sale de tu equipo.
- Que diferencia hay entre datos falsos, de prueba y simulados?
- En la practica, ninguna: los tres terminos nombran lo mismo y esta pagina sirve para todos. Lo que importa es la forma: registros estructurados con columnas con nombre y tipo, a diferencia del texto de relleno como el lorem ipsum, que ocupa el diseno pero no se puede cargar en una base de datos ni en una API.
- Como uso la salida SQL?
- La salida son sentencias INSERT simples contra el nombre de tabla que indiques, una por fila, asi que funciona en cualquier cliente SQL. Las cadenas se escapan duplicando las comillas, los numeros van sin comillas y los booleanos se escriben TRUE y FALSE. Los nombres de columna o tabla que no sean identificadores simples se entrecomillan con comillas dobles.
- Por que el limite es de 1.000 filas?
- Mil filas de JSON ya son unos 100KB de texto, que es el punto en el que un area de texto empieza a ir lenta. Si necesitas mas, genera por lotes: la columna de ID vuelve a empezar en 1 cada vez, asi que ajustala si vas a cargarlo todo en la misma tabla.
- Es buena la aleatoriedad?
- Viene de crypto.getRandomValues con muestreo por rechazo, la misma fuente sin sesgo que este sitio usa para generar contrasenas y UUID. Importa menos para nombres de ciudades ficticias que para contrasenas, pero mantener una sola implementacion de aleatoriedad significa que solo hay una que acertar.
Última actualización:
Incluye los pasos, el resultado esperado y el real. Elimina secretos y datos personales.