34.1 Introducción
En este último tema aplicaremos los conceptos del curso en un caso práctico. No usaremos una tecnología específica, porque el objetivo es aprender a pensar una prueba de integración: alcance, componentes, datos, dependencias, escenarios, verificaciones y reporte.
El caso será una funcionalidad de compra en una tienda en línea. Este ejemplo permite integrar capas internas, base de datos, proveedor de pagos simulado y publicación de eventos.
La intención es mostrar cómo convertir una necesidad funcional en un conjunto claro de pruebas de integración.
34.2 Descripción del sistema
Supongamos una aplicación de comercio electrónico con estos componentes:
- Controlador de compras: recibe la solicitud para confirmar una compra.
- Servicio de compras: coordina reglas de negocio.
- Repositorio de órdenes: guarda órdenes e ítems.
- Base de datos: almacena clientes, productos, stock, órdenes y pagos.
- Servicio de pagos: autoriza o rechaza pagos.
- Publicador de eventos: publica un evento cuando la orden queda confirmada.
El objetivo del caso práctico es verificar que estos componentes colaboren correctamente para confirmar o rechazar una compra.
34.3 Requisito principal
El requisito funcional principal será:
El sistema debe confirmar una compra cuando el cliente está activo, el producto tiene stock suficiente y el pago es aprobado.
Cuando la compra se confirma, el sistema debe:
- Crear una orden.
- Guardar los ítems comprados.
- Descontar stock.
- Registrar el pago aprobado.
- Publicar un evento de orden confirmada.
34.4 Reglas adicionales
Además del camino exitoso, definimos algunas reglas importantes:
- Si el cliente no está activo, la compra debe rechazarse.
- Si no hay stock suficiente, la compra debe rechazarse.
- Si el pago es rechazado, la orden no debe quedar confirmada.
- Si el proveedor de pagos no responde, la compra debe quedar pendiente o rechazarse según la regla definida.
- No debe publicarse evento de orden confirmada si la compra no fue confirmada.
Estas reglas nos permiten diseñar casos positivos, negativos y de error técnico.
34.5 Alcance de las pruebas
Para este caso, definimos este alcance:
- Usaremos controlador, servicio de compras y repositorios reales.
- Usaremos una base de datos real de prueba.
- Usaremos un servicio de pagos simulado.
- Usaremos una cola o publicador de eventos de prueba.
- No enviaremos correos reales ni haremos cobros reales.
Este alcance permite verificar colaboración interna, persistencia y eventos, sin depender de un proveedor real de pagos.
34.6 Dependencias reales y simuladas
La decisión sobre dependencias se puede resumir así:
| Dependencia |
Decisión |
Motivo |
| Base de datos |
Real de prueba |
Queremos verificar persistencia, stock, órdenes y pagos. |
| Servicio de pagos |
Simulado |
Necesitamos controlar aprobación, rechazo y timeout. |
| Publicador de eventos |
Real de prueba o fake verificable |
Queremos confirmar si el evento se publicó y con qué contenido. |
| Correo |
Fuera del alcance |
No forma parte del objetivo de este caso. |
34.7 Datos iniciales
Para ejecutar las pruebas necesitaremos datos controlados:
- Cliente activo.
- Cliente inactivo.
- Producto activo con stock suficiente.
- Producto activo con stock insuficiente.
- Precio definido para el producto.
- Forma de pago de prueba.
Estos datos deben crearse para la prueba o cargarse de manera reproducible. No deben depender de carga manual.
34.8 Caso 1: compra aprobada
Este es el camino positivo principal.
| Objetivo |
Verificar que una compra válida se confirme correctamente. |
| Datos |
Cliente activo, producto con stock 10, compra de 2 unidades. |
| Dependencia simulada |
Pagos devuelve aprobado. |
| Resultado esperado |
Orden confirmada, stock 8, pago aprobado registrado y evento publicado. |
34.9 Verificaciones del caso aprobado
Para la compra aprobada no alcanza con verificar una respuesta exitosa. Debemos comprobar el estado final:
- La orden existe en la base de datos.
- La orden tiene estado confirmado o pagado, según el modelo definido.
- Los ítems de la orden coinciden con la compra solicitada.
- El stock se redujo correctamente.
- El pago quedó registrado con identificador del proveedor simulado.
- Se publicó un evento de orden confirmada con los campos obligatorios.
34.10 Caso 2: stock insuficiente
Este caso verifica una regla de negocio negativa.
| Objetivo |
Verificar que una compra sin stock suficiente sea rechazada. |
| Datos |
Cliente activo, producto con stock 1, compra de 2 unidades. |
| Dependencia simulada |
El proveedor de pagos no debería ser invocado. |
| Resultado esperado |
Compra rechazada, stock sin cambios, sin pago y sin evento de confirmación. |
34.11 Caso 3: pago rechazado
Este caso verifica que una respuesta negativa del proveedor de pagos no deje la compra como confirmada.
- Preparar cliente activo y producto con stock suficiente.
- Configurar proveedor simulado para devolver pago rechazado.
- Ejecutar confirmación de compra.
- Verificar que la orden no quede confirmada.
- Verificar que el stock no quede descontado definitivamente.
- Verificar que no se publique evento de orden confirmada.
Este caso protege contra estados inconsistentes después de errores externos.
34.12 Caso 4: timeout del proveedor de pagos
Este caso verifica un error técnico.
La decisión esperada depende de la regla del sistema. Por ejemplo, puede definirse que la orden quede pendiente de pago.
- Configurar proveedor simulado para no responder a tiempo.
- Ejecutar compra.
- Verificar respuesta controlada.
- Verificar que la orden no quede pagada.
- Verificar que el stock no se descuente definitivamente.
- Verificar que quede evidencia del timeout.
34.13 Caso 5: compra exacta del stock disponible
Este es un caso límite. Si el producto tiene stock 2 y la compra pide 2 unidades, la operación debería aceptarse si la regla permite agotar stock.
Verificaciones:
- La compra se confirma.
- El stock queda en 0.
- No se rechaza por falta de stock.
- La orden y el pago quedan registrados.
- Se publica evento de orden confirmada.
Este caso ayuda a detectar errores de comparación, como usar menor estricto cuando corresponde menor o igual.
34.14 Trazabilidad de los casos
Podemos relacionar los casos con requisitos y riesgos:
| Caso |
Requisito o riesgo cubierto |
| Compra aprobada |
Confirmar compra válida con pago aprobado. |
| Stock insuficiente |
Evitar ventas sin disponibilidad. |
| Pago rechazado |
Evitar orden confirmada sin pago aprobado. |
| Timeout de pagos |
Manejar fallas temporales de dependencia externa. |
| Compra exacta del stock |
Validar límite de disponibilidad. |
34.15 Evidencia esperada
Durante la ejecución, conviene reunir evidencia útil:
- Datos iniciales creados para la prueba.
- Respuesta de la operación.
- Estado de la orden en base de datos.
- Stock antes y después.
- Respuesta del servicio de pagos simulado.
- Evento publicado, si corresponde.
- Identificador de correlación para seguir el flujo.
Esta evidencia permite diagnosticar fallas sin revisar todo el sistema manualmente.
34.16 Limpieza
Después de cada prueba, el ambiente debe quedar limpio. En este caso, la limpieza puede incluir:
- Eliminar órdenes creadas.
- Eliminar pagos registrados.
- Restaurar o eliminar productos de prueba.
- Eliminar clientes de prueba si fueron creados para el caso.
- Vaciar eventos publicados en la cola de prueba.
- Reiniciar el servicio de pagos simulado.
Sin limpieza, una prueba podría afectar el resultado de la siguiente.
34.17 Reporte final del caso práctico
Un reporte simple podría indicar:
- Alcance: compras, stock, pagos simulados, base de datos y eventos.
- Casos ejecutados: compra aprobada, stock insuficiente, pago rechazado, timeout y límite de stock.
- Dependencias reales: base de datos de prueba y publicador de eventos de prueba.
- Dependencias simuladas: proveedor de pagos.
- Riesgos pendientes: no se validó proveedor real de pagos ni envío real de correos.
Este reporte permite entender qué confianza aporta la prueba y qué queda fuera de su alcance.
34.18 Errores que debemos evitar
En este caso práctico, conviene evitar:
- Verificar solo la respuesta de compra sin revisar base de datos.
- Usar datos compartidos de otros escenarios.
- No limpiar órdenes y eventos.
- Simular pagos aprobados siempre y no probar rechazos.
- No verificar que el evento no se publique cuando la compra falla.
- No documentar que el proveedor de pagos real quedó fuera del alcance.
34.19 Qué debes recordar de este caso
- Un caso práctico de integración empieza con requisitos y reglas claras.
- El alcance debe indicar componentes reales y dependencias simuladas.
- Los datos iniciales deben ser controlados.
- Las verificaciones deben incluir respuesta, estado final y ausencia de efectos indebidos.
- Los casos negativos y de error técnico son esenciales.
- El reporte debe explicar qué se cubrió y qué quedó fuera.
34.20 Conclusión del curso
Las pruebas de integración permiten verificar que los componentes de un sistema colaboren correctamente. A lo largo del curso vimos conceptos, estrategias, ambientes, datos, contratos, dependencias, errores, automatización, diagnóstico y buenas prácticas.
La idea principal es que una prueba de integración debe tener un propósito claro: comprobar una colaboración relevante con suficiente realismo, datos controlados, verificaciones útiles y evidencia para diagnosticar fallas.
Con estos fundamentos, ya puedes avanzar hacia cursos más específicos como pruebas end-to-end, testing de APIs REST, mocking, automatización, CI/CD y testing en distintos lenguajes.