Generador de direcciones aleatorias para pruebas: manual de QA 2026

Un fixture escrito a mano codifica una sola suposición, y normalmente es la dirección del propio autor. Ese único valor rara vez cubre un nombre de calle largo, una unidad secundaria, un código de territorio o un país cuyo código postal contiene letras. Cada caso no cubierto es un defecto esperando a que lo descubra un cliente.

La generación aleatoria con semilla fija da amplitud sin renunciar a la estabilidad. Puedes generar cien direcciones de 38 países, volver a ejecutar exactamente las mismas cien mañana y aun así plantar casos límite concretos donde quieras. El generador cubre 38 países con cinco fixtures de ciudad cada uno, así que la amplitud está acotada y se conoce, en lugar de depender de lo que internet produjera ese día.

Hay una segunda ventaja que los fixtures escritos a mano nunca tienen: cobertura negativa. Un autor suele escribir valores que espera que funcionen, lo que significa que la suite ejercita el camino feliz y lo da por completo. Un generador con semilla más una lista explícita de casos límite también ejercita los límites, y cuando uno falla, el informe nombra la semilla y la regla que produjo el valor en lugar de un literal que alguien escribió hace años.

El muestreo uniforme sobre 38 países no es una carga de trabajo. El tráfico real está muy sesgado hacia el mercado en el que vendes y usa sobre todo uno o dos países. Si tu prueba extrae países de forma uniforme, el 90 por ciento de las ejecuciones se dedica a locales que tus clientes nunca tocan, y el único mercado que importa recibe una fracción de la cobertura.

Elige pesos en lugar de aleatoriedad pura. Da al mercado principal la mayor parte del volumen, da a los mercados secundarios una cuota que puedas justificar y reserva una pequeña porción para países de cola larga cuyos formatos difieren estructuralmente, como Japón con su orden de líneas invertido o los Países Bajos con letras después de los dígitos. Añade Hong Kong y los Emiratos Árabes Unidos de forma explícita, porque ninguno tiene código postal y expondrán un error de campo obligatorio en la primera ejecución.

Sembrar solo funciona si una semilla llega a todas las capas. Si la API genera un registro en la preparación de la prueba y el navegador genera otro durante el relleno del formulario, los dos no coinciden y la aserción falla por el motivo equivocado. Pasa la semilla por la fábrica de fixtures, el payload de la API y el helper del navegador como un único valor, y regístrala en el informe de la prueba.

El generador tiene semilla y es reproducible, así que la misma semilla produce las mismas direcciones en el mismo orden. Deriva sub-semillas de la semilla padre y de un índice estable para que añadir una prueba en medio no renumere todos los registros posteriores. Eso mantiene comparables los artefactos y capturas guardados entre ejecuciones, lo que importa cuando un diff visual es la única señal que tienes.

La aleatoriedad correcta depende del nivel. Las pruebas unitarias quieren valores pequeños y explícitos que hagan obvia la aserción. Las pruebas de integración quieren longitudes de campo realistas. Las pruebas de extremo a extremo quieren valores que sobrevivan a un navegador real y a un serializador real. Las pruebas de carga quieren volumen y una distribución estable, no variedad.

Un error común es usar fixtures completos de extremo a extremo en todas partes. Eso hace ilegibles los fallos unitarios y ralentiza el bucle interno. El error opuesto, usar una dirección fija para e2e, oculta todas las ramas específicas de cada país. Elige el fixture más pequeño que pueda hacer fallar el comportamiento bajo prueba.

La aleatoriedad acabará produciendo un nombre de calle largo, pero no producirá deliberadamente una unidad secundaria de 35 caracteres ni un código postal con un espacio final. Esos casos son baratos de plantar y caros de pasar por alto. Genéralos desde una lista explícita en lugar de esperar que la distribución colabore.

Planta casos en el límite y uno más allá. Si la línea 1 está limitada a 100 caracteres, prueba 99, 100 y 101. Si el campo postal recorta espacios en blanco, prueba un valor con un espacio inicial y un valor con un espacio de no separación, porque son caracteres distintos y normalmente solo uno de ellos se recorta.

Una aserción que compara la dirección renderizada con una cadena generada literal es frágil: se rompe cuando cambia el fixture y no demuestra nada sobre el comportamiento. Afirma las propiedades de las que es responsable la aplicación. El país debe ir y volver sin cambios. El código postal debe coincidir con el patrón del país seleccionado. La fila almacenada debe ser igual a los valores enviados tras la normalización documentada.

Un patrón útil es una tabla de aserciones de forma compartida entre pruebas: para cada país, una regex del código postal, el número esperado de líneas de dirección y si la región es obligatoria. Así, cualquier valor generado, con cualquier semilla, o cumple el contrato o revela una divergencia real. La prueba deja de importarle qué nombre de calle salió del generador.

Las direcciones generadas solo son seguras de almacenar donde todos aceptan que son falsas. Dales un marcador inconfundible: un email en el dominio reservado example.test, un registro de cliente marcado como fixture o un tenant dedicado en staging. El generador ya limita los números de teléfono al rango de ficción NANP 555-0100 a 555-0199 y los emails a example.test precisamente por esto.

Nunca siembres una base de datos de staging compartida que también leen ventas o soporte sin avisarles, y nunca copies una fila de staging a producción para depurar un informe. Las filas generadas parecen plausibles, que es su propósito y su peligro. Si un fixture se escapa a una tabla de analítica, las cifras de conversión se mueven y nadie puede distinguir qué pedidos eran reales.