Los datos de identidad en un fixture de pruebas son la parte del proyecto que nadie revisa hasta que una prueba falla dos veces seguidas con resultados distintos. Un fixture es el conjunto de datos que se prepara antes de ejecutar una prueba para que el sistema tenga algo con lo que trabajar. Cuando está bien hecho, un fallo se puede reproducir en cualquier máquina; cuando está hecho de cualquier manera, cada ejecución cuenta una historia distinta.
Qué es un fixture y en qué se diferencia de un dato cualquiera
Un fixture es un dato con un propósito declarado. No es simplemente un registro que se cuela en la base de datos para que no esté vacía: es la entrada concreta de un caso de prueba concreto, y existe porque ese caso la necesita. La diferencia se nota al leerlo. Un registro de relleno se llama como se llame y da igual su contenido; un registro de fixture se llama como el escenario que cubre y su contenido está elegido.
En el caso de las identidades, esa distinción importa más que en otros dominios, porque la mayoría de los casos interesantes no dependen del valor de un campo sino de la relación entre varios: una persona justo en el límite de edad, un nombre que no cabe en el campo, un documento con una longitud poco habitual.
¿Por qué conviene que las muestras no cambien?
Porque un fallo solo se puede arreglar si se puede volver a ver. Cuando la prueba genera una identidad nueva en cada ejecución, el informe de error describe un registro que ya no existe; quien lo lee no puede reproducirlo ni comprobar si el arreglo funciona. La prueba se convierte en una moneda al aire: pasa casi siempre, y cuando falla nadie sabe por qué.
Una muestra fija resuelve las dos mitades del problema. Las afirmaciones sobre el resultado se mantienen estables, porque la entrada no cambia, y un fallo se puede repetir tantas veces como haga falta hasta entenderlo. La contrapartida es que hay que elegir bien las muestras y mantenerlas, algo que se aborda más abajo.
Cómo nombrar y organizar los registros
El criterio que mejor funciona es nombrar cada registro por el escenario que cubre, no por el valor que contiene. Un nombre que describe la situación sobrevive a los cambios; un nombre que repite el dato se queda obsoleto en cuanto alguien ajusta el valor.
Conviene además mantener una correspondencia clara entre registro y caso de prueba. Si dos pruebas comparten una muestra, modificar esa muestra por un motivo rompe la otra sin avisar. Y si una prueba usa tres registros distintos para lo mismo, se multiplican los sitios donde hay que tocar cuando cambie el modelo de datos. La experiencia en el ámbito de las direcciones es la misma, y está recogida en la guía sobre datos de dirección en ficheros de prueba.
¿Qué casos límite conviene tener preparados?
La tentación es guardar tres identidades corrientes y confiar en que los casos raros aparecerán solos en producción. Estos son los que conviene preparar de antemano, porque son los que rompen pantallas y validaciones.
- Una persona muy mayor, para comprobar que la edad y la fecha de nacimiento se calculan bien en los extremos.
- Un nombre muy largo, con varias partes y algún guion, para ver qué hace el diseño cuando el texto no cabe.
- Una persona sin apellido, para verificar que el sistema guarda el registro en lugar de exigir un valor que no existe.
- Un nombre escrito en un alfabeto no latino, para comprobar que el campo, la búsqueda y el informe lo admiten.
- Una persona justo en un umbral de edad, para los casos en los que el sistema aplica reglas distintas según los años.
- Un registro con un campo opcional vacío, para que la rama que trata la ausencia de valor se ejecute alguna vez.
- Un documento con una longitud poco habitual, si el sistema atiende a varios países.
No hace falta que todos estén presentes desde el primer día. Lo que importa es que la lista exista y que alguien la revise cuando se añada un país o cambie el modelo de datos. Los detalles sobre nombres en distintos alfabetos están en la guía sobre datos de nombre por idioma y región.
Cómo crear el material del fixture
Los registros de un fixture no deberían salir de una base de datos real ni de una lista de personas conocidas. Lo práctico es generarlos una vez, revisarlos y guardarlos como parte del proyecto.
En el generador de datos de identidad de este sitio se elige el país y la división administrativa y se obtiene un registro con nombre, dirección, documento, teléfono y perfil en línea coherentes entre sí. La clave de identidad que acompaña a cada registro permite volver a obtener exactamente el mismo valor cuando haga falta regenerarlo, de modo que la muestra se puede guardar como una referencia corta en lugar de como un bloque de texto.
Notas para quien programa
- Guarda el fixture en el control de versiones. Un conjunto de datos que solo existe en la máquina de una persona no es un fixture, es una costumbre. En el repositorio, cualquier cambio pasa por revisión.
- Evita la generación aleatoria dentro de la prueba. Si el valor se sortea al ejecutar, el fallo no es reproducible. Genera una vez, fija el resultado y afirma sobre él.
- Documenta qué cubre cada muestra. Una nota breve junto al registro evita que alguien lo borre por parecer raro cuando en realidad estaba cubriendo un caso límite.
- Revisa el fixture cuando cambie el modelo. Los campos nuevos dejan a las muestras antiguas sin valor y las validaciones nuevas no se ejecutan con ellas. Añade un caso por cada regla que aparezca.
- Anota la fecha de creación. Un fixture envejece: los umbrales de edad dejan de cumplirse, las muestras dejan de ser válidas y nadie se da cuenta hasta que la prueba falla por un motivo que no tiene que ver con el código. La guía sobre verificación de edad en pruebas es el ejemplo más claro de este desgaste.
Siguientes pasos
Elige las tres muestras que más usas y comprueba si están nombradas por escenario y si alguien más sabría para qué sirven. Después añade las dos que falten de la lista de casos límite: suelen ser las que descubren el error de verdad.
Para construir esas muestras sin usar datos de nadie, el generador de datos de identidad entrega registros completos con su clave de identidad. Ese material es solo para pruebas de software, no corresponde a ninguna persona real y no permite hacerse pasar por otra ni superar una verificación de identidad.