Una prueba de integración útil no nace por ejecutar varios componentes juntos sin criterio. Necesita un diseño claro: qué colaboración se quiere verificar, qué datos se usarán, qué dependencias participan y qué resultado demostrará que la integración funciona.
Diseñar casos de prueba de integración ayuda a evitar pruebas confusas, demasiado amplias o difíciles de diagnosticar. También permite que el equipo entienda qué riesgo cubre cada prueba.
En este tema veremos cómo estructurar un caso de prueba de integración desde su objetivo hasta sus verificaciones finales.
Un caso de prueba de integración describe una situación donde dos o más componentes colaboran y deben producir un resultado esperado.
Debe indicar:
El primer paso es escribir un objetivo claro. El objetivo debe indicar la colaboración que se quiere verificar.
Ejemplos de objetivos claros:
Un objetivo como “probar compras” es demasiado amplio. No indica qué integración se quiere validar.
El alcance define qué componentes participan en la prueba. Debe quedar claro qué se incluye y qué se deja fuera.
Por ejemplo, para una compra podríamos incluir:
Definir el alcance evita confundir una prueba de integración específica con una prueba end-to-end o de sistema completo.
Cada caso debe identificar qué dependencias necesita y cómo serán tratadas.
Conviene responder:
Una dependencia no documentada puede convertirse en una causa oculta de fallas.
Los datos iniciales deben ser suficientes para ejecutar el caso y deben estar bajo control de la prueba.
Un buen diseño indica:
Los datos deben ser fáciles de entender. Si el caso necesita muchos datos, conviene revisar si el escenario está demasiado mezclado.
La acción es el disparador de la integración. Puede ser una llamada a un servicio, una solicitud a un controlador, la llegada de un mensaje, la carga de un archivo o la ejecución de un proceso.
Ejemplos:
La acción debe ser única y claramente relacionada con el objetivo del caso.
Una prueba de integración puede verificar más de un resultado, pero todas las verificaciones deben estar relacionadas con el objetivo.
Puede verificar:
En integración, muchas veces el estado final es tan importante como la respuesta.
El resultado esperado debe ser concreto. No alcanza con decir “debe funcionar”. Debe indicar qué observaremos para decidir si la prueba pasó.
Ejemplos:
pendiente.orden_creada con el identificador correcto.Un resultado esperado claro es indispensable para interpretar una falla.
Los casos positivos verifican que la integración funcione cuando las condiciones son válidas.
Ejemplos:
Estos casos establecen el comportamiento esperado del camino principal.
Los casos negativos verifican cómo se comporta la integración cuando algo no permite completar la operación.
Ejemplos:
En estos casos, es fundamental verificar que no queden cambios parciales incorrectos.
Además de errores de negocio, las integraciones pueden fallar por problemas técnicos.
Casos importantes:
Estos casos ayudan a evaluar robustez y diagnóstico.
El nombre de un caso debe comunicar su intención. Un buen nombre permite entender qué colaboración se verifica sin leer todo el contenido.
Ejemplos de nombres útiles:
Los nombres genéricos dificultan el mantenimiento de la suite.
Una plantilla simple puede ayudar a diseñar casos consistentes:
| Objetivo | Qué colaboración se quiere verificar. |
|---|---|
| Componentes | Partes reales que participan en la prueba. |
| Dependencias simuladas | Qué se reemplaza y qué respuesta dará. |
| Datos iniciales | Estado necesario antes de ejecutar. |
| Acción | Operación que dispara la integración. |
| Resultado esperado | Respuesta, estado final y efectos esperados. |
| Limpieza | Cómo se eliminan datos o recursos creados. |
Un caso diseñado para compra aprobada podría verse así:
| Objetivo | Verificar que una compra aprobada cree orden, descuente stock y registre pago. |
|---|---|
| Componentes | Servicio de compras, repositorio, base de datos de prueba. |
| Dependencia simulada | Proveedor de pagos devuelve aprobado. |
| Datos iniciales | Cliente activo, producto con 10 unidades, precio definido. |
| Acción | Confirmar compra de 2 unidades. |
| Resultado esperado | Orden pagada, stock en 8 unidades, pago registrado. |
| Limpieza | Eliminar orden, pago y producto creados para la prueba. |
Al diseñar casos de integración, suelen aparecer errores como:
Antes de implementar o ejecutar un caso de integración, conviene revisar:
Diseñar bien un caso de prueba de integración permite obtener información precisa sobre la colaboración entre componentes. Una prueba clara reduce el tiempo de diagnóstico y evita que la suite se vuelva un conjunto de ejecuciones difíciles de interpretar.
El diseño debe responder siempre qué se prueba, con qué datos, contra qué dependencias y qué resultado demostrará que la integración funcionó.
En el próximo tema veremos pruebas positivas, negativas y casos límite en integración.