Cómo Usar Datos Ficticios en Pruebas de Software
Usar datos reales de CPF, CNPJ o tarjeta de crédito en ambientes de desarrollo y homologación es un riesgo jurídico y ético. Entienda cómo los datos ficticios matemáticamente válidos hacen las pruebas más seguras, reproducibles y conformes con la LGPD.
Por qué los datos ficticios son indispensables en las pruebas
Todo sistema que recopila datos de usuarios — sea un e-commerce, un sistema bancario, una app de RH o una plataforma de salud — necesita ser probado extensivamente antes de ir a producción. La tentación de usar datos reales es grande: son convenientes y representan situaciones verdaderas. Pero esta práctica crea riesgos serios. La LGPD (Ley 13.709/2018) prohíbe el uso de datos personales para finalidades incompatibles con la recopilación original. Un ambiente de desarrollo con datos reales de clientes puede resultar en multas de hasta el 2% de la facturación anual de la empresa, limitadas a R$ 50 millones por infracción.
Además del riesgo jurídico, existe el riesgo operacional: datos reales en ambientes de prueba son frecuentemente accedidos por desarrolladores, proveedores de servicio y herramientas de CI/CD que no deberían tener contacto con información personal. Una vez que esos datos se filtran, el daño a la reputación de la empresa es irreparable. Los datos ficticios eliminan estos riesgos: se prueba con la misma estructura y complejidad de los datos reales, sin ninguna exposición de personas físicas o jurídicas.
¿Qué significa 'matemáticamente válido'?
No basta generar cualquier secuencia numérica — necesita pasar las mismas validaciones que el sistema aplica. El CPF, por ejemplo, tiene dos dígitos verificadores calculados por el algoritmo de módulo 11. Si inserta un CPF con dígitos aleatorios, el sistema de validación lo rechazará antes de que llegue al flujo que quiere probar. Lo mismo vale para CNPJ, CNH, RENAVAM, Título de Elector y otros documentos brasileños.
Help4Dev genera datos que pasan todas estas verificaciones algorítmicas. Un CPF generado aquí tiene la estructura correcta y dígitos verificadores válidos — pasará por la capa de validación de su aplicación, permitiendo que pruebe el comportamiento real del sistema: persistencia en la base de datos, integración con APIs externas, generación de reportes y todos los flujos de negocio.
Estrategias para organizar datos ficticios en proyectos
Una buena práctica es crear un archivo de fixtures o seeds con datos ficticios fijos para los escenarios más comunes de su sistema. Por ejemplo: un CPF de persona física estándar, un CNPJ de empresa activa, una tarjeta de crédito de cada marca principal. Estos datos quedan versionados en el repositorio y son usados de forma consistente por todo el equipo y los pipelines de CI/CD.
Para pruebas que exigen variación — como verificar si el sistema maneja correctamente múltiples registros — use generadores programáticos que creen datos ficticios válidos bajo demanda. Bibliotecas como Faker (disponible para Python, JavaScript, Java, Ruby) ofrecen generadores de CPF y CNPJ en algunas implementaciones. Complementar con las herramientas del Help4Dev para validar los datos generados es siempre una buena verificación adicional.
Casos de uso más comunes
Registro de usuarios: formularios que exigen CPF, RG o CNH necesitan ser probados con documentos válidos de diferentes estados. E-commerce: flujos de checkout que validan CPF del comprador y CNPJ de la empresa emisora de la factura. Sistemas de RH: registro de colaboradores con PIS/PASEP, CPF y datos de cartera de trabajo. Salud: plataformas que emiten AIH necesitan números válidos para probar integraciones con el DATASUS.
En todos estos casos, Help4Dev ofrece generadores específicos para cada tipo de documento, con opciones de máscara (con o sin puntos y guiones) y rotación automática para generar múltiples valores rápidamente durante sesiones de prueba manual.
Integrando datos ficticios en pipelines de automatización
Frameworks de prueba como Cypress, Playwright, Selenium y JUnit permiten parametrizar casos de prueba con múltiples conjuntos de datos. Un enfoque eficiente es mantener un archivo JSON o CSV con 10 a 20 CPFs y CNPJs ficticios válidos e iterar sobre ellos en las pruebas de registro y validación. Esto aumenta la cobertura sin aumentar la complejidad de los scripts.
Para automatizaciones más sofisticadas, considere crear un microservicio interno o una función utilitaria que implemente los algoritmos de generación de CPF y CNPJ en el lenguaje de su proyecto. Los algoritmos son públicos y de fácil implementación — nuestro artículo sobre el algoritmo del CPF y CNPJ explica el paso a paso completo.