Genera datos de prueba
reales. Sin datos reales.

Qué son los datos de prueba y por qué no vale usar «12345678»

Un dato de prueba sirve para dos cosas opuestas: confirmar que el sistema acepta lo que debe aceptar y confirmar que rechaza lo que debe rechazar. La mayoría de los equipos solo cubre la primera. Escriben 12345678 en el campo de DNI, la validación de longitud pasa y el caso queda «probado» hasta que producción recibe un DNI con un cero delante, un RUC con dígito verificador incorrecto o una tarjeta que no cumple Luhn. Este generador nace de ese problema: cada herramienta ofrece la variante válida y la variante que rompe, con el motivo explicado.

Qué encontrarás en cada pestaña

Documentos peruanos: qué se valida de verdad

El DNI peruano tiene 8 dígitos y admite ceros a la izquierda: si tu campo es numérico en lugar de texto, un DNI que empieza por cero llegará mutilado a la base de datos. Además existe un dígito (o letra) verificador que se imprime en el documento y que muchos sistemas piden por separado.

El RUC son 11 dígitos con estructura clara: los dos primeros indican el tipo de contribuyente (10 para persona natural con negocio, 20 para persona jurídica, 15 y 17 para formatos antiguos) y el último es un dígito verificador calculado con módulo 11 y los pesos 5·4·3·2·7·6·5·4·3·2. En los RUC de tipo 10, los ocho dígitos centrales son el DNI del titular: una relación que conviene reproducir en los datos de prueba si tu sistema la comprueba.

El carné de extranjería usa hoy 9 dígitos y no tiene dígito verificador público, así que la única validación razonable es el formato y la longitud. Los formatos antiguos alfanuméricos siguen circulando en registros históricos: si tu aplicación los rechaza de plano, conviene saberlo antes de migrar datos.

Tarjetas de prueba: Luhn no es lo mismo que «válida»

Todos los números de tarjeta cumplen el algoritmo de Luhn: una suma ponderada que detecta errores de tecleo. Que un número pase Luhn significa que está bien escrito, no que exista una cuenta detrás. Por eso los números que genera esta web son perfectos para probar máscaras de entrada, detección de marca por prefijo y validación en cliente, y por eso nunca podrán cobrar nada. Para probar el flujo completo de pago necesitas las tarjetas de sandbox de tu pasarela (Culqi, Niubiz, Izipay, Stripe): la opción «números de sandbox conocidos» incluye los clásicos 4111 1111 1111 1111 y 4242 4242 4242 4242.

Casos límite: donde de verdad se rompen las aplicaciones

La sección de casos límite es la que más defectos encuentra. Una cadena de 5 000 caracteres contra un VARCHAR(255); un emoji que ocupa un carácter en pantalla, dos unidades UTF-16 en JavaScript y cuatro bytes en UTF-8; el 29 de febrero de 1900 (que no existe, porque 1900 no fue bisiesto); el 0.1 + 0.2 que no da 0.3; el instante 2038-01-19T03:14:08Z que desborda un entero de 32 bits. Cada valor viene con su explicación, de modo que puedes pegarlo en el reporte de la incidencia tal cual.

Buenas prácticas al usar datos sintéticos

• Nunca en producción. Los datos sintéticos ensucian los reportes y pueden tener consecuencias contables.
• Márcalos. Usa un prefijo reconocible (QA-, dominio example.com) para poder borrarlos después.
• No sustituyen a la anonimización. Si necesitas trabajar con datos reales, anonimízalos según la Ley N.º 29733 de Protección de Datos Personales; generar datos nuevos es más seguro que «disfrazar» los verdaderos.
• Guarda el lote junto al caso de prueba. Exporta el CSV y adjúntalo: un defecto reproducible vale el doble.

Todo se ejecuta en tu navegador con JavaScript. No hay servidor, ni cuenta, ni analítica de tus valores: puedes abrir el inspector de red y comprobar que no se envía nada. Si tu equipo trabaja sin conexión, la web sigue funcionando una vez cargada.