Testing de Integración

Qué es

El testing de integración verifica que dos o más componentes funcionen correctamente cuando interactúan entre sí. El foco cambia respecto del unit test:

Unit:        ¿este componente se comporta correctamente?
Integration: ¿estos componentes interactúan correctamente?

En ReservaResto, un caso natural es ReservationService contra PostgreSQL:

Crear reserva → Persistir (ReservationService) → PostgreSQL (test container) → Leer reserva → Verificar resultado esperado

Acá la base de datos es real —aislada en un test environment o un container—, a diferencia del unit test, donde esa dependencia estaba reemplazada por un double.

Qué problemas detecta

Los tests de integración son particularmente buenos para encontrar errores que los unit tests no pueden ver: SQL incorrecto, mappings de ORM mal configurados, problemas de serialización/deserialización, transaction boundaries mal definidos, schema mismatches, problemas de configuración, o fallas en la integración con un message broker (por ejemplo, si ReservaResto publica un evento reservation.created para que NotificationService lo consuma).

Un unit test puede demostrar que el código arma correctamente un objeto Reservation. No demuestra que el ORM lo persista como esperamos.

Test doubles vs dependencias reales

Conviene evitar la simplificación de “unit tests usan mocks, integration tests no”. La pregunta correcta es otra:

¿Qué límite queremos verificar?

Si queremos verificar la interacción real con PostgreSQL, necesitamos PostgreSQL. Si lo que queremos verificar es solamente una business rule, probablemente no.

Qué NO detecta

Un test de integración de ReservationService contra la base de datos no prueba que el flujo de negocio completo funcione: no prueba que la seña se cobre, que la mesa quede bloqueada para otros usuarios, ni que la confirmación efectivamente le llegue al comensal. Eso es responsabilidad del siguiente nivel.

Y hay un límite que ni siquiera el nivel siguiente cubre bien: si NotificationService es un servicio aparte con su propio ciclo de deploy, un test de integración verifica que tu lado del contrato funciona, no que el otro lado siga entendiéndolo. Ese es el problema que trata backward compatibility en APIs, y la razón por la que los sistemas de comunicación asíncrona necesitan versionar sus eventos.