Las pruebas de integración necesitan datos. Sin datos adecuados, los componentes no pueden ejecutar reglas reales, consultar dependencias, guardar resultados ni demostrar que colaboran correctamente.
Pero los datos de prueba también pueden convertirse en una fuente de problemas. Si son ambiguos, compartidos sin control o difíciles de recrear, las pruebas pueden fallar de manera impredecible.
En este tema veremos cómo diseñar y preparar datos de prueba para que las pruebas de integración sean claras, repetibles y fáciles de diagnosticar.
Los datos de prueba son los valores y registros que una prueba necesita para ejecutarse. Pueden existir antes de la prueba, crearse durante la ejecución o verificarse al final como resultado esperado.
En una prueba de integración, los datos pueden estar en distintos lugares:
En pruebas unitarias, muchas veces se crean datos pequeños dentro de la misma prueba. En integración, los datos suelen atravesar varias partes del sistema y quedar guardados o transformados.
Por eso los datos importan para verificar:
Una buena práctica es preparar solo los datos necesarios para el objetivo de la prueba. Si cargamos demasiados datos, la prueba puede volverse confusa y difícil de mantener.
Por ejemplo, para probar que se crea una orden de compra, tal vez solo necesitemos:
Si agregamos decenas de usuarios, productos y promociones que no participan en el caso, aumentamos el ruido sin aportar valor.
Los datos deben parecerse a situaciones que el sistema puede encontrar. No hace falta copiar producción, pero sí conviene usar valores que representen casos reales del negocio.
Ejemplos de datos representativos:
Los datos demasiado artificiales pueden ocultar defectos que aparecerían con datos más cercanos al uso real.
Los caminos exitosos verifican que una integración funcione cuando todo está preparado correctamente. Son importantes porque establecen la base esperada del comportamiento.
Un camino exitoso debe tener datos coherentes:
Por ejemplo, una compra exitosa necesita usuario válido, producto disponible, stock suficiente y respuesta aprobada del pago.
Las pruebas de integración también deben cubrir situaciones donde el sistema rechaza una operación o maneja una falla. Para eso necesitamos datos negativos o inválidos.
Ejemplos:
Estos datos ayudan a verificar que la integración no deje estados inconsistentes cuando una operación falla.
Los datos límite son valores cercanos a una frontera importante. Son útiles porque muchos errores aparecen en esos bordes.
Ejemplos de datos límite:
En integración, estos datos permiten comprobar que varios componentes interpretan el límite de la misma manera.
Los datos semilla son datos base que se cargan antes de ejecutar pruebas. Pueden representar catálogos, roles, estados, configuraciones o entidades comunes.
Ejemplos:
Los datos semilla deben ser estables y conocidos. Si cambian sin control, muchas pruebas pueden empezar a fallar.
En muchos proyectos se usan fixtures o fábricas para crear datos de prueba. Un fixture es un conjunto de datos predefinido. Una fábrica es una función o herramienta que genera datos con valores por defecto y permite modificar lo necesario.
| Enfoque | Ventaja | Cuidado |
|---|---|---|
| Fixture fijo | Es fácil de leer y repetir. | Puede volverse rígido o demasiado compartido. |
| Fábrica de datos | Permite crear datos específicos para cada prueba. | Debe generar datos coherentes y comprensibles. |
| Datos creados en la prueba | Hace explícito lo que necesita el caso. | Puede generar repetición si no hay helpers adecuados. |
Una decisión importante es si las pruebas usarán datos compartidos o datos propios. Los datos compartidos pueden simplificar la preparación, pero también generan acoplamiento entre pruebas.
Los datos propios de cada prueba suelen ser más confiables porque:
Los datos compartidos pueden usarse para catálogos estables, pero conviene evitar usarlos para entidades que se modifican durante la prueba.
Cuando una prueba crea datos, es útil usar identificadores únicos. Esto evita choques con datos de otras pruebas o ejecuciones anteriores.
Ejemplos:
usuario-test-123@example.com.Los identificadores únicos no reemplazan la limpieza, pero ayudan a reducir interferencias y facilitan investigar resultados.
Las pruebas no deberían usar datos personales reales, contraseñas reales, tarjetas reales ni información productiva sin protección. Si se necesitan datos parecidos a producción, deben ser ficticios o anonimizados.
Cuidados básicos:
La calidad de una prueba no justifica poner en riesgo información sensible.
Después de ejecutar una prueba, los datos creados o modificados deben limpiarse o aislarse. Si no, las pruebas futuras pueden recibir un ambiente contaminado.
Formas habituales de limpieza:
La estrategia elegida depende de la tecnología y del costo de preparar el ambiente.
Supongamos una prueba para verificar que una orden se crea y descuenta stock. Los datos podrían organizarse así:
| Tipo de dato | Ejemplo | Uso en la prueba |
|---|---|---|
| Usuario | Cliente activo. | Permite crear la orden. |
| Producto | Producto activo con precio definido. | Permite calcular el total. |
| Stock | 10 unidades disponibles. | Permite descontar la cantidad comprada. |
| Pago simulado | Respuesta aprobada. | Permite completar el flujo exitoso. |
| Resultado esperado | Orden creada y stock reducido. | Permite verificar estado final. |
Al trabajar con datos de prueba, conviene evitar:
Los datos de prueba determinan en gran parte la confiabilidad de una prueba de integración. Una prueba puede estar bien escrita, pero fallar o perder valor si sus datos son inconsistentes, incompletos o impredecibles.
Preparar buenos datos permite ejecutar escenarios claros, verificar estados finales y diagnosticar fallas con mayor precisión.
En el próximo tema veremos cómo manejar estado inicial, limpieza y aislamiento entre pruebas, profundizando en uno de los aspectos más importantes para evitar pruebas inestables.