Cómo genero datos de prueba sin filtrar información real de clientes
Una vez encontré números de tarjetas de crédito reales en una base de datos de prueba. Nunca más. Así es como construyo datos ficticios realistas que no ponen en riesgo a nadie.
Aquí va una confesión: al principio de mi carrera, probé un flujo de pago usando mi propia tarjeta de crédito. Número real. Fecha de caducidad real. CVV real. Tenía 22 años, estaba solo un viernes por la noche, y pensé: "Qué podría salir mal?"
Todía tengo pesadillas con ese archivo CSV flotando por algún lado.
Hoy en día soy un poco más cuidadoso. En realidad, mucho más cuidadoso. Que te queme tu propia estupidez una vez es suficiente.
El Problema con los Datos Reales
Cuando estás construyendo una aplicación que procesa pagos, gestiona cuentas o almacena información personal, necesitas datos de prueba realistas. Nombres falsos. Correos electrónicos falsos. Números de tarjeta de crédito falsos que parezcan válidos pero no lo sean. El problema es que la mayoría de los desarrolladores optan por la opción más fácil: volcar datos de producción en un entorno de prueba y listo.
Así es como ocurren las filtraciones. Así es como terminas en la portada de Hacker News con un titular que empieza con "Base de datos no asegurada expone..."
Mi Configuración Actual
Uso dos herramientas en combinación, y han cambiado completamente mi flujo de trabajo.
Primero, el generador de UUID. Cada usuario de prueba en mi sistema recibe un UUID en lugar de un ID autoincremental. Por qué? Porque los UUIDs no filtran información. No te dicen cuántos usuarios tengo, ni cuál se registró primero, ni ninguno de los otros metadatos que los IDs secuenciales revelan accidentalmente. Además, hacen que mi base de datos de prueba se vea elegante y futurista.
Segundo — y esto es lo que realmente marca la diferencia — uso el generador de tarjetas de crédito de prueba (sí, tenemos uno). Genera números que pasan la comprobación del algoritmo de Luhn (para que parezcan lo suficientemente reales para la lógica de validación), pero provienen de rangos de prueba conocidos. Los números de prueba de Visa empiezan con 4. MasterCard con 5. Ninguno de ellos cobrará a nadie. He configurado mi pipeline de CI para generar números de tarjeta nuevos para cada ejecución de prueba. Sin almacenamiento, sin riesgo, sin estrés.
Más Allá de Tarjetas e IDs
Para el resto de mis datos de prueba, uso una filosofía similar. Nombres falsos de generadores de nombres aleatorios. Direcciones de correo electrónico que se enrutan a un dominio de prueba de captura general. Direcciones de la lista oficial de direcciones ficticias del USPS (sí, eso existe — el servicio postal es sorprendentemente complaciente con escenarios imaginarios).
La regla de oro: si podría ser el dato de una persona real, no debería estar en tu base de datos de prueba. Eso incluye el número de teléfono de tu tía Linda, el correo electrónico de tu antiguo compañero de piso, o — Dios no lo quiera — tu propia tarjeta de crédito.
No Necesitas Ser Paranoico, Solo Cuidadoso
No estoy diciendo que necesites una auditoría de seguridad completa solo para ejecutar una prueba unitaria. Pero tomarte cinco minutos para generar datos de prueba adecuados — usando un generador de UUID aquí, un generador de tarjetas de prueba allá — es la diferencia entre un flujo de trabajo de desarrollo seguro y un desastre esperando ocurrir. Y honestamente, es más divertido. Los datos falsos significan que puedes dar a tus usuarios de prueba nombres como "Crash Override" y "Acid Burn" sin ser demandado.
Confía en mí. Tu yo futuro — y tus clientes — te lo agradecerán.