Generador de direcciones aleatorias

Por qué usar direcciones generadas en las pruebas

Copiar la dirección real de un cliente en una base de datos de staging, en un ticket de error o en una demo es muy fácil, y es justo el tipo de tratamiento de datos que regula la ley de privacidad. Según el RGPD, una dirección postal vinculada a una persona es un dato personal, y los entornos de prueba no son una excepción: la minimización de datos y la limitación de la finalidad también se aplican ahí.

• Los tickets viajan: un informe de error acaba pegado en el chat, enlazado desde pull requests y exportado a otras herramientas. Todo lo que contiene, incluida la captura de un formulario rellenado, viaja con él.
• Staging está menos protegido: los sistemas de prueba suelen tener más accesos, menos monitorización y más tiempo de retención que producción. Los registros reales ahí suman riesgo sin sumar cobertura de pruebas.
• Las demos se graban: las demos comerciales, los vídeos de onboarding y las capturas de la documentación acaban siendo públicos. Una dirección generada parece real en pantalla sin señalar a nadie.
• El formato sigue importando: un texto de relleno como «prueba prueba 123» nunca pone a prueba tu validación. Las direcciones generadas siguen el formato de código postal y el orden de líneas reales de cada país, así que los parsers, el formateo y la lógica de envíos trabajan con datos realistas.

Si un error solo se reproduce con los datos de un cliente concreto, reconstruye la forma de ese registro (mismo país, mismas longitudes de campo, mismos caracteres especiales) con valores generados en lugar de copiar el registro.

Cómo se construye cada dirección

• Lugares reales que encajan: cada ciudad sale de una lista revisada con su estado, provincia o región reales y códigos postales que le pertenecen. Eso significa códigos ZIP completos en Estados Unidos, distritos postales reales en el Reino Unido, forward sortation areas reales (los tres primeros caracteres) en Canadá y códigos postales reales en Alemania, España, Francia y Australia.
• Finales válidos pero aleatorios: en el Reino Unido y Canadá los tres últimos caracteres son aleatorios pero siguen el patrón oficial, así que el código completo puede no corresponder a un punto de entrega real.
• Calles verosímiles: los nombres de calle se forman con patrones habituales de cada país, como Maple Avenue, Station Road, Lindenstraße, Calle Mayor o rue de la République, con números y datos de piso al estilo local. Una calle y un número concretos pueden existir o no.
• Teléfonos que no son de nadie: los números salen solo de rangos reservados para ficción en Estados Unidos, Canadá, el Reino Unido, Australia, Alemania y Francia. En España la opción está desactivada porque no hemos podido confirmar un rango reservado.
• Correos en dominios reservados: todos los correos usan example.com, example.org o example.net, que el RFC 2606 reserva para documentación. Nadie puede registrarlos, así que detrás no hay ningún buzón real. Cada correo es único dentro de una tanda, algo útil para probar una restricción de correo único.
• Aleatoriedad segura: cada elección usa crypto.getRandomValues del navegador, así que las tandas no siguen patrones predecibles.

Formatos de dirección por país

El generador muestra cada dirección en el orden de líneas que espera el servicio postal de cada país. Esto es lo que cambia de un país a otro, después del nombre del destinatario:

Alemania y Francia no incluyen la región en la dirección postal, y en el Reino Unido el condado es opcional. Un formulario que exige un estado para cualquier país rechaza direcciones perfectamente válidas de esos lugares.

Casos límite que QA debería probar en formularios de dirección

Los formularios de dirección fallan siempre en los mismos puntos. Genera una tanda por cada país al que envías y revisa esto:

• Nombres de calle largos: Avenida de los Reyes Católicos o Hans-Böckler-Straße chocan con límites de longitud ajustados y se cortan mal en las etiquetas. Revisa cada sitio donde acaba la dirección: el formulario, el correo de confirmación, las facturas, los PDF y cualquier API de envíos o de pagos, que a menudo admite menos caracteres que tu propio formulario.
• Caracteres no ASCII: sigue la ß, la ñ, la é y la ü desde la entrada hasta la exportación. Un valor UTF-8 leído como Windows-1252 convierte München en «München». Revisa también las mayúsculas: en JavaScript, "Straße".toUpperCase() devuelve "STRASSE", lo que puede romper comparaciones exactas.
• Pisos, puertas y apartamentos: comprueba que la segunda línea opcional sobrevive a cada paso. El orden también cambia: en el Reino Unido y Francia el piso o apartamento va encima de la calle. En España el piso y la puerta van en la misma línea de la calle, en Alemania la vivienda o la planta siguen al número tras //, y en Estados Unidos, Canadá y Australia la unidad también va en la línea de la calle.
• Códigos postales con letras y espacios: los postcodes británicos y los códigos postales canadienses mezclan letras y dígitos alrededor de un espacio. Acepta minúsculas y la falta del espacio, y después normaliza (sw1a1aa pasa a SW1A 1AA). No uses nunca type="number" para un campo de código postal.
• Ceros a la izquierda: Boston (02108), Dresde (01067), Barcelona (08001), Niza (06000) y Darwin (0800) empiezan por cero. Guarda los códigos postales como texto, nunca como enteros. Excel quita el cero si abres un CSV con doble clic, así que impórtalo desde Datos, Desde texto/CSV y define la columna como Texto.
• Direcciones sin estado o provincia: un desplegable de estado obligatorio bloquea a usuarios alemanes y franceses. Haz que el campo, su etiqueta y su validación dependan del país elegido.
• Autorrelleno y autocomplete: usa los tokens estándar (name, address-line1, address-line2, address-level2 para la ciudad, address-level1 para el estado o la provincia, postal-code, country, tel, email) y comprueba que el autorrelleno del navegador llena las casillas correctas. Después cambia el país y confirma que las etiquetas y la validación se actualizan.
• Apóstrofos y guiones: St. John's, O'Brien y Saint-Étienne están en los datos a propósito. Destapan errores de escape en SQL, HTML y CSV, y validaciones que solo admiten letras.