Los datos de dirección en fixtures de prueba son ese material del que casi nadie se ocupa hasta que una suite empieza a fallar sin motivo aparente. Una fixture es simplemente un conjunto de datos preparado de antemano para que una prueba se ejecute siempre en las mismas condiciones. Cuando esos datos son direcciones, hay tres exigencias que no se pueden saltar: que sean reproducibles, que estén aislados entre sí y que cubran los casos difíciles, no solo el caso cómodo.
Por qué las fixtures importan más de lo que parece
Una dirección es un dato compuesto. Una prueba que comprueba un total, una factura o un cálculo de envío depende de que todos los componentes de la dirección encajen entre ellos; si la ciudad y el código postal proceden de regiones distintas, la prueba puede pasar o fallar por un motivo que no tiene nada que ver con lo que se quería verificar.
Eso convierte a las direcciones en una fuente silenciosa de resultados intermitentes. La prueba no falla porque el código esté mal, sino porque los datos de entrada eran incoherentes desde el principio. Y como el fallo aparece lejos de su causa, se acaba culpando al componente equivocado.
¿Se pueden usar direcciones reales en las pruebas?
Técnicamente se puede copiar un registro de la base de datos de producción y usarlo como fixture, y es una práctica que conviene abandonar. La razón principal es que una dirección es un dato personal: identifica a una persona o a un domicilio, y su presencia en un repositorio de código, en un entorno de pruebas o en un registro de ejecución amplía el alcance del tratamiento sin ninguna necesidad.
Hay además una razón práctica. Los datos copiados de producción cambian: la persona se muda, el registro se actualiza o se borra, y la prueba que dependía de ese valor exacto empieza a comportarse de manera distinta según el entorno. Una fixture tiene que ser estable, y un dato real nunca lo es del todo.
La alternativa es generar datos verosímiles que no pertenezcan a nadie. El generador de direcciones falsas produce registros coherentes por país, y son solo para pruebas de software: no corresponden a ninguna vivienda ni destinatario real ni deben usarse para enviar nada.
Las propiedades que debe cumplir una buena fixture
- Determinista. La misma fixture debe producir el mismo resultado en cada ejecución. Si incluye valores generados al azar sin semilla fija, la prueba deja de ser reproducible.
- Aislada. Dos pruebas no deben compartir registros si una de ellas los modifica. La misma dirección reutilizada en varios escenarios acaba generando dependencias invisibles entre pruebas.
- Coherente por dentro. La ciudad, la división administrativa y el código postal deben pertenecer a la misma zona, salvo que el escenario que se está probando sea precisamente el del desajuste.
- Legible. Quien lea la fixture debe entender qué caso representa. Un nombre descriptivo ahorra minutos cada vez que alguien investiga un fallo.
- Mínima. Solo los campos que la prueba necesita. Una fixture con veinte campos que nadie mira se vuelve difícil de mantener y oculta cuál es la condición que importa.
¿Qué casos límite conviene cubrir?
El objetivo de una fixture no es representar la media, sino los extremos. Un conjunto que solo contiene direcciones bien formadas de un solo país no demuestra nada sobre el comportamiento real del sistema.
Merece la pena incluir un registro de un país que escribe las líneas en orden inverso al habitual, otro con caracteres que no son latinos, otro cuyo país no usa código postal, otro con la unidad o el apartamento relleno y otro sin ella, y por supuesto una dirección con la división administrativa y el código postal en desacuerdo. Este último caso está desarrollado con más detalle en la guía sobre códigos postales que no cuadran, y conviene revisar además qué parte de una dirección se puede comprobar antes de escribir la fixture que lo reproduce.
También conviene incluir valores en el límite de longitud: la línea de calle más larga que el sistema admite, un nombre con un solo carácter y campos opcionales vacíos. Son los que destapan errores de truncado y de validación excesiva.
| Escenario | Qué comprueba |
|---|---|
| Orden de líneas invertido | Composición y presentación del bloque |
| Alfabeto no latino | Codificación y conservación del original |
| País sin código postal | Campos opcionales y mensajes de la interfaz |
| División y código en desacuerdo | Coherencia interna y detección de errores |
| Línea en el máximo de longitud | Truncado y límites del formulario |
Cómo organizar el conjunto de fixtures
La organización más útil separa lo que es dato de lo que es escenario. Los datos base —un puñado de direcciones completas por país, sin nada especial— se guardan aparte y se reutilizan. Encima de ellos se definen variantes para los casos límite, cada una con su nombre.
Esa separación evita el problema clásico de las suites que crecen: cada prueba nueva añade su propia dirección completa, y al cabo del tiempo hay doscientas direcciones distintas de las que nadie sabe cuál sigue siendo necesaria. Con una base pequeña y variantes explícitas, se puede borrar una variante sin miedo a romper otra cosa.
Otra decisión útil es dónde viven los datos. Si están escritos dentro del código de la prueba, cualquier cambio de valor obliga a tocar el código. Si están en un fichero de datos, se pueden revisar y actualizar sin riesgo de introducir un error de programación por el camino.
Notas para quien programa
- Nunca copies producción. Una fixture no necesita ser real para ser válida, y las direcciones reales son datos personales que no deberían salir de su entorno.
- Semilla fija si generas. Un dato aleatorio sin semilla convierte una prueba reproducible en una lotería.
- Cifras claramente ficticias. Es preferible que quien lea la fixture reconozca a primera vista que el dato es de prueba.
- Una variante, un propósito. Si una fixture cubre dos casos a la vez y falla, no se sabe cuál de los dos la rompió.
- Revisa las fixtures al cambiar el esquema. Al añadir un campo obligatorio, todas las fixtures antiguas quedan incompletas y las pruebas fallan por un motivo ajeno a lo que comprueban.
- No compartas fixtures entre idiomas ni entre países. Lo que es un caso límite en un país puede ser la norma en otro.
Siguientes pasos
Revisa las fixtures actuales y busca direcciones copiadas de un entorno real; si encuentras alguna, sustitúyela por un registro generado y comprueba que la prueba sigue pasando. Después añade un caso límite que hoy no esté cubierto, empezando por el desajuste entre división administrativa y código postal. El generador te da el material de partida en un par de clics, siempre como datos de prueba.