Un generador de direcciones aleatorias produce registros postales variados para llenar un entorno de desarrollo, una base de datos de staging o un conjunto de pruebas automatizadas. La palabra aleatorio invita a pensar que cualquier combinación de valores sirve, y esa es precisamente la suposición que arruina la mayoría de los intentos caseros: una dirección al azar cuyos campos no encajan entre sí no prueba nada, solo genera ruido que después hay que limpiar a mano. En las páginas siguientes se explica qué tiene que respetar el azar para resultar útil, por qué la reproducibilidad importa más que la variedad y qué fallos aparecen casi siempre cuando se generan registros de varios países a la vez. Al terminar sabrás cómo pedir el material que necesitas y cómo comprobar que sirve para lo que quieres medir.
Aleatorio no significa arbitrario
Cuando se genera una dirección, el azar debe operar dentro de un espacio de valores válidos. Los estados o provincias pertenecen a un catálogo cerrado, los códigos postales tienen una forma definida y a menudo una correspondencia con la división administrativa, y las ciudades no se reparten de manera uniforme por el territorio. Elegir cada campo de una lista independiente produce combinaciones imposibles con una frecuencia mucho mayor de la que sugiere la intuición.
Hay una razón adicional para restringir el azar: el material de prueba debe parecerse a lo que el sistema recibirá en producción. Si el conjunto contiene proporciones irreales, como la misma cantidad de registros para una región diminuta que para la más poblada del país, las pruebas de rendimiento y de interfaz dan resultados engañosos. La variedad útil no es la que maximiza combinaciones distintas, sino la que reproduce la distribución que el sistema verá de verdad.
De ahí sale una regla sencilla que conviene aplicar en cualquier herramienta. Primero se elige el país, después la división administrativa dentro de ese país, y luego los valores locales que dependen de ella. Cada decisión restringe el espacio de la siguiente, y el resultado es un registro que parece aleatorio al mirarlo y que es internamente consistente al comprobarlo.
¿Por qué conviene que el mismo identificador devuelva siempre la misma dirección?
La reproducibilidad es la propiedad menos visible y la más valiosa. Un informe de fallo que menciona una dirección concreta solo sirve si otra persona puede volver a obtener esa misma dirección sin acceso a la base de datos donde se detectó el problema. Si cada consulta devuelve un valor nuevo, la única forma de reproducir un fallo es copiar el dato a mano, y esa copia se pierde en cuanto alguien limpia el entorno.
La forma habitual de resolverlo es asociar cada registro a una clave. Con la misma clave y el mismo país, el generador devuelve siempre el mismo valor; con otra clave, devuelve otro. Eso permite guardar junto al código una lista corta de claves, o incluso una sola clave por escenario de prueba, y reconstruir cualquier registro pasado meses después sin haber almacenado un dato personal.
Esta propiedad también cambia la manera de escribir las pruebas. En lugar de fijar un valor y compararlo con el resultado esperado, la prueba pide el registro por su clave y verifica reglas sobre él: que el código postal sea válido para el estado, que el teléfono corresponda a la ciudad, que la unidad sea opcional. Esas comprobaciones siguen teniendo sentido cuando el catálogo de datos se actualiza, mientras que una comparación literal contra un valor congelado obliga a reescribir la prueba cada vez que cambia el conjunto.
La coherencia entre campos es la parte difícil
La coherencia interna es donde se distinguen las herramientas serias de las que solo rellenan huecos. En una dirección, la división administrativa determina el código postal y las ciudades disponibles; en un registro de identidad, la fecha de nacimiento determina la edad y el país determina la forma del documento y del teléfono. Cuando esos vínculos se rompen, el registro deja de ser un caso válido y se convierte en un caso imposible que ningún usuario real produciría.
El problema es que un desajuste no siempre salta a la vista. Un listado de cien registros con códigos postales plausibles parece correcto hasta que se comprueba que las tres cuartas partes no corresponden al estado que figura al lado. Esa comprobación cruzada es una de las pocas validaciones de dirección que se pueden hacer sin consultar ningún servicio externo, y por eso conviene que el generador la garantice por construcción en lugar de dejarla al criterio de quien usa el material.
La misma lógica se aplica a los dígitos de control. Cuando un identificador incluye un dígito verificador, un valor inventado tiene muchas probabilidades de fallar la comprobación, y ese fallo detiene la prueba antes de que se haya ejercitado la lógica que interesaba. El repaso de estos vínculos está en la guía sobre la coherencia entre campos de identidad, que resulta útil antes de definir qué se exige a un conjunto de datos.
¿Cómo se usa una dirección aleatoria en pruebas de carga?
En una prueba de carga el objetivo no es descubrir un caso límite, sino medir cómo se comporta el sistema con un volumen que se parece al real. Ahí la variedad importa por un motivo concreto: un sistema que indexa direcciones puede comportarse de forma muy distinta con mil registros repetidos que con mil registros distintos, porque los planes de consulta cambian según la distribución de los valores.
También importa el reparto geográfico. Si el sistema agrupa pedidos por región o calcula plazos de entrega por zona, generar toda la carga con direcciones de una sola provincia oculta los problemas de contención que aparecen cuando la mayoría de las peticiones caen en la misma partición. Un conjunto que respeta la distribución del país de origen da una medida mucho más cercana a la realidad.
Conviene además separar el material de la ejecución. Si la prueba genera direcciones nuevas en cada pasada, dos ejecuciones no son comparables y ninguna tendencia sirve para decidir. Lo razonable es preparar un conjunto fijo, guardarlo junto al plan de pruebas y reutilizarlo mientras la lógica no cambie. El papel de los ficheros de datos en este contexto se desarrolla en la guía sobre datos de dirección en ficheros de prueba.
Exportar en lote para pruebas dirigidas por datos
Cuando el volumen crece, la forma cómoda de trabajar es la exportación. Un fichero separado por comas con mil registros y sus campos bien delimitados se puede leer desde cualquier lenguaje: cada línea es un caso de prueba, y añadir un caso nuevo consiste en añadir una línea. Eso convierte el material en un activo del repositorio, revisable como cualquier otro cambio de código.
Hay dos detalles que deciden si esa exportación resulta útil. El primero es la codificación: los nombres de calle y de localidad llevan caracteres acentuados en casi todos los idiomas, y un fichero guardado en la codificación equivocada llega destrozado al otro extremo. El segundo es el tratamiento de los ceros iniciales, porque una hoja de cálculo que interpreta un código postal numérico como número los elimina sin avisar. Guardar esos campos como texto evita el problema desde el principio.
También merece la pena conservar la clave de cada registro dentro del fichero. Cuando una prueba falla en la línea cuatrocientos, la clave permite volver a pedir exactamente ese registro desde el generador y aislarlo sin arrastrar todo el conjunto. La guía sobre validación y normalización de direcciones explica por qué ese trabajo de formato debe hacerse antes de comparar valores, y no después.
Los desajustes más frecuentes en un conjunto multinacional
En cuanto el conjunto mezcla países, aparecen fallos que no existían dentro de una sola frontera. El más común es tratar la división administrativa como un campo universal: en algunos países el equivalente al estado es obligatorio y en otros no existe, y forzar un valor en esos casos produce datos que ningún usuario podría introducir. Lo mismo ocurre con el código postal, que en ciertos países no forma parte de la dirección en absoluto.
El segundo es la mezcla de catálogos. Un generador que toma la ciudad de una lista y el código postal de otra, aunque ambas sean correctas por separado, produce registros que no corresponden a ningún lugar. El tercero es la asociación entre teléfono y localidad, donde el prefijo de área pertenece a una zona concreta y un número con el prefijo de una ciudad grande junto a una dirección de otra región es un dato imposible.
Para evitar esta clase de problemas, la estrategia sensata es generar cada registro dentro de un solo país y no combinar piezas entre países distintos. Las diferencias que hay que tener en cuenta al escoger mercados están resumidas en la guía sobre cómo elegir países para datos de prueba. Si el sistema que se prueba es internacional, conviene empezar por dos o tres países con modelos muy distintos y ampliar después.
Qué papel juega el azar en las pruebas de formularios
Además del volumen, el azar bien dirigido sirve para encontrar entradas que rompen el analizador. El objetivo no es golpear el sistema con caracteres al azar, sino variar de forma sistemática los elementos que suelen dar problemas: números de portal con letra, nombres de vía con puntos cardinales, unidades escritas con abreviaturas distintas, localidades cuyo nombre coincide con el de otra región del mismo país.
Esa exploración se complementa con la prueba de valores límite, donde el azar no interviene o interviene poco. Un campo que admite sesenta caracteres se prueba con sesenta y con sesenta y uno, y un campo obligatorio se prueba vacío, con espacios y con un valor válido. La combinación de ambas técnicas cubre más terreno que cualquiera de las dos por separado, y el material generado aporta la parte de variedad que escribir a mano no alcanza.
Al final, lo que hace útil al azar es la restricción que lo acompaña. Un registro aleatorio dentro de un espacio de valores válidos y coherentes es un buen caso de prueba; un registro aleatorio sin restricciones es un error esperando a que alguien lo interprete como un fallo del sistema.
Los límites de este material
Los registros que produce un generador son datos sintéticos. Su forma y sus correspondencias son correctas porque se han construido siguiendo las convenciones del país, pero no pertenecen a ninguna persona ni a ningún domicilio real, y no figuran en ningún catálogo postal. Que resulten verosímiles no los convierte en direcciones reales.
Su sitio está en el entorno de desarrollo, en la integración continua y en la demostración interna. No sirven para acreditar una dirección ante un tercero, para abrir cuentas ni para superar una comprobación de identidad, y esa frontera es también la razón por la que este material no genera obligaciones de protección de datos para quien lo utiliza.
Siguientes pasos
Antes de generar nada, decide tres cosas: cuántos registros necesita la prueba, de qué países y con qué distribución geográfica. Con esa lista, el generador de direcciones aleatorias devuelve el material en unos segundos y permite repetir exactamente el mismo conjunto a partir de una clave. Si quieres comparar dos modelos nacionales muy distintos dentro del mismo ejercicio, el generador de direcciones de Turquía ofrece una jerarquía mucho más profunda que la estadounidense. Recuerda el límite: son datos de prueba generados para probar software, no corresponden a ninguna persona real y no sirven para acreditar nada.