17. Integración entre servicios internos

17.1 Introducción

En muchas aplicaciones, una funcionalidad no vive en un único módulo. Puede estar distribuida entre varios servicios internos que colaboran para completar una operación.

Un servicio de ventas puede consultar productos, stock, usuarios, pagos y notificaciones. Aunque todos pertenezcan a la misma organización, cada servicio puede tener su propio contrato, datos, reglas y forma de responder ante errores.

Las pruebas de integración entre servicios internos verifican que esa colaboración funcione correctamente y que los servicios se entiendan entre sí.

17.2 Qué es un servicio interno

Un servicio interno es un componente que ofrece una capacidad a otras partes del sistema dentro de la misma aplicación, plataforma u organización.

Puede ser:

  • Un módulo interno con una interfaz clara.
  • Un servicio separado dentro de una arquitectura distribuida.
  • Un microservicio.
  • Un proceso de negocio invocado por otros componentes.
  • Un servicio de infraestructura mantenido por el equipo.

La diferencia con un servicio externo es que el equipo suele tener mayor influencia sobre su contrato, su disponibilidad y su evolución.

17.3 Qué se prueba en esta integración

Al probar la integración entre servicios internos, nos interesa verificar:

  • Que el consumidor pueda invocar al servicio correcto.
  • Que los datos enviados respeten el contrato.
  • Que la respuesta sea interpretada correctamente.
  • Que los errores se manejen de forma controlada.
  • Que los estados entre servicios sean coherentes.
  • Que los cambios de un servicio no rompan a sus consumidores.
La integración entre servicios internos no consiste solo en comprobar conectividad. También verifica acuerdos, datos, reglas y coordinación.

17.4 Comunicación síncrona entre servicios

La comunicación síncrona ocurre cuando un servicio llama a otro y espera una respuesta inmediata para continuar.

Ejemplo: el servicio de ventas consulta al servicio de stock antes de confirmar una compra.

Aspectos a probar:

  • La solicitud contiene los datos esperados.
  • El servicio llamado responde con el formato correcto.
  • El consumidor interpreta la respuesta adecuadamente.
  • Se manejan errores y timeouts.
  • No se realiza la operación si la dependencia indica que no corresponde continuar.

17.5 Comunicación asíncrona entre servicios

La comunicación asíncrona ocurre cuando un servicio publica un mensaje o evento para que otro lo procese después. El productor no espera necesariamente una respuesta inmediata.

Ejemplo: el servicio de órdenes publica un evento de orden confirmada y el servicio de notificaciones lo consume para enviar un mensaje.

Aspectos a probar:

  • El evento se publica en el canal correcto.
  • El mensaje tiene el formato esperado.
  • El consumidor puede procesarlo.
  • El estado final aparece dentro de un tiempo razonable.
  • Los mensajes duplicados o inválidos se manejan correctamente.

17.6 Contratos entre servicios

Cada servicio expone un contrato para sus consumidores. Ese contrato puede incluir rutas, métodos, eventos, campos, códigos de error, estados y reglas de uso.

Al probar integración entre servicios, conviene verificar:

  • Campos obligatorios y opcionales.
  • Tipos de datos.
  • Formatos de fecha, moneda o identificadores.
  • Estados posibles.
  • Errores esperados.
  • Compatibilidad con versiones anteriores cuando aplique.

Un pequeño cambio de contrato puede romper varios consumidores internos si no se detecta a tiempo.

17.7 Datos compartidos entre servicios

Los servicios internos pueden compartir conceptos de negocio, aunque no compartan una misma base de datos. Por ejemplo, varios servicios pueden hablar de usuario, pedido, producto o cuenta.

Problemas frecuentes:

  • Un servicio interpreta un estado de forma distinta a otro.
  • Un identificador tiene distinto formato según el servicio.
  • Una fecha se interpreta en otra zona horaria.
  • Un campo opcional para el productor es obligatorio para el consumidor.
  • Dos servicios calculan una regla de manera diferente.

Las pruebas de integración deben usar datos que revelen estas diferencias.

17.8 Disponibilidad de servicios internos

Un servicio interno puede no estar disponible por fallas, despliegues, errores de red o configuración. La integración debe manejar estas situaciones de forma controlada.

Conviene probar qué ocurre cuando:

  • El servicio no responde.
  • Responde con error temporal.
  • Responde más lento de lo esperado.
  • Devuelve datos incompletos.
  • La URL o credencial está mal configurada.

El objetivo no siempre es que la operación continúe. A veces el comportamiento correcto es rechazarla, dejarla pendiente o registrar el problema.

17.9 Versionado

Los servicios evolucionan. Un servicio puede agregar campos, cambiar reglas o exponer una nueva versión de su contrato. Las pruebas de integración ayudan a detectar incompatibilidades.

Riesgos de versionado:

  • Un consumidor antiguo no reconoce un nuevo estado.
  • Un campo deja de enviarse.
  • Una validación se vuelve más estricta.
  • Una respuesta cambia de estructura.
  • Dos servicios no fueron desplegados en versiones compatibles.

Las integraciones internas deben considerar cómo se despliegan cambios y qué consumidores dependen de cada contrato.

17.10 Autenticación y permisos entre servicios

Aunque los servicios sean internos, muchas veces necesitan autenticarse o demostrar permisos para invocarse entre sí.

Las pruebas pueden verificar:

  • Que el consumidor envíe credenciales válidas.
  • Que el servicio rechace llamadas no autorizadas.
  • Que los permisos correspondan al tipo de operación.
  • Que los errores de autorización no se confundan con errores de negocio.
  • Que la configuración de seguridad sea distinta a producción.

Un error de permisos puede bloquear integraciones aunque los datos y contratos sean correctos.

17.11 Observabilidad entre servicios

Cuando varios servicios colaboran, diagnosticar una falla puede ser más difícil. Por eso la observabilidad es importante.

Conviene contar con:

  • Logs claros en cada servicio.
  • Identificadores de correlación.
  • Mensajes de error útiles.
  • Registro de solicitudes y respuestas relevantes.
  • Estado final verificable.

Una prueba fallida debe permitir saber qué servicio recibió qué datos y dónde se rompió la colaboración.

17.12 Usar servicios reales o simulados

Al probar integración entre servicios internos, podemos usar servicios reales en un ambiente de prueba o simular algunos de ellos.

Enfoque Ventaja Riesgo
Servicios reales Mayor confianza sobre la colaboración real. Más preparación, dependencia de disponibilidad y diagnóstico más complejo.
Servicio simulado Mayor control sobre respuestas, errores y tiempos. Puede quedar desactualizado respecto del contrato real.
Combinación Permite enfocar la prueba en una integración concreta. Requiere documentar qué se está verificando realmente.

17.13 Ejemplo: ventas y stock

Supongamos que el servicio de ventas necesita consultar al servicio de stock antes de confirmar una orden.

Una prueba de integración puede verificar:

  • Ventas envía identificador de producto y cantidad solicitada.
  • Stock responde disponibilidad y cantidad actual.
  • Ventas confirma la orden si hay stock suficiente.
  • Ventas rechaza la orden si no hay stock suficiente.
  • El estado final no deja orden confirmada sin disponibilidad.

Este escenario prueba una regla compartida entre dos servicios internos.

17.14 Ejemplo: órdenes y notificaciones

Otro caso común es la integración entre un servicio de órdenes y un servicio de notificaciones.

La prueba puede verificar que:

  • Al confirmar una orden se publique un evento correcto.
  • El evento incluya identificador de orden, cliente y canal de contacto.
  • El servicio de notificaciones consuma el evento.
  • Se registre la notificación enviada o pendiente.
  • Un evento inválido no provoque una falla descontrolada.

Este ejemplo muestra una integración asíncrona donde el resultado puede aparecer después de un breve tiempo.

17.15 Errores comunes

Al probar integración entre servicios internos, suelen aparecer errores como:

  • Usar contratos no documentados.
  • Probar solo el camino exitoso.
  • No controlar versiones compatibles.
  • Depender de servicios compartidos inestables.
  • No distinguir errores técnicos de errores de negocio.
  • No verificar el estado final después de una llamada.
  • Simular servicios con respuestas demasiado diferentes de las reales.

17.16 Lista de verificación

Antes de considerar cubierta una integración entre servicios internos, conviene revisar:

  • ¿Está claro qué servicio consume y qué servicio produce?
  • ¿El contrato de datos está verificado?
  • ¿Se prueban respuestas exitosas y errores relevantes?
  • ¿La configuración apunta al ambiente correcto?
  • ¿Se verifica el estado final del flujo?
  • ¿Las versiones de los servicios son compatibles?
  • ¿Los logs permiten diagnosticar una falla?

17.17 Qué debes recordar de este tema

  • Los servicios internos también necesitan contratos claros y pruebas de integración.
  • La comunicación puede ser síncrona o asíncrona.
  • Los datos compartidos deben interpretarse igual entre servicios.
  • La disponibilidad, el versionado y los permisos son fuentes frecuentes de errores.
  • Usar servicios reales aumenta realismo; simular aumenta control.
  • La observabilidad es clave para diagnosticar fallas entre varios servicios.

17.18 Conclusión

La integración entre servicios internos permite comprobar que distintas capacidades del sistema colaboran correctamente. Aunque los servicios pertenezcan al mismo equipo u organización, sus contratos, datos y estados deben verificarse.

Estas pruebas ayudan a detectar incompatibilidades, errores de configuración, problemas de versionado y fallas de coordinación antes de que afecten flujos más amplios.

En el próximo tema veremos la integración con APIs y sistemas externos.