1. ¿Qué son las pruebas de integración?

1.1 Introducción

Las pruebas de integración son pruebas que verifican si dos o más partes de un sistema funcionan correctamente cuando trabajan juntas. No se enfocan solamente en una función aislada, sino en la colaboración entre módulos, clases, servicios, bases de datos, archivos, colas de mensajes, APIs u otros componentes.

Un programa puede tener partes individuales bien construidas y, aun así, fallar cuando esas partes se conectan. Esto ocurre porque los componentes deben intercambiar datos, respetar formatos, manejar errores, compartir configuraciones y coordinar su comportamiento.

Por eso las pruebas de integración ocupan un lugar central dentro del testing: ayudan a descubrir problemas que no aparecen en una prueba unitaria, pero que todavía pueden detectarse antes de probar todo el sistema completo de punta a punta.

1.2 Una definición simple

Podemos definirlas de esta manera:

Esta definición contiene varias ideas importantes:

• Varios componentes: la prueba involucra más de una parte del sistema.
• Comunicación: se revisa que las llamadas, mensajes o consultas lleguen correctamente.
• Intercambio de datos: se verifica que los datos enviados y recibidos tengan el formato, el contenido y el significado esperados.
• Colaboración: se comprueba que las partes conectadas produzcan un resultado útil en conjunto.
• Tarea concreta: la prueba debe tener un objetivo claro, no solo ejecutar código porque sí.

1.3 ¿Por qué son necesarias?

Las pruebas unitarias ayudan a comprobar piezas pequeñas de código. Sin embargo, muchos defectos aparecen recién cuando esas piezas se conectan. Una clase puede estar bien programada, un servicio puede responder correctamente y una base de datos puede funcionar, pero la integración entre ellos puede fallar.

Algunos problemas frecuentes son:

• Un componente envía un dato con un nombre distinto al que espera otro componente.
• Una consulta a la base de datos devuelve un valor nulo que el código no sabe manejar.
• Un servicio responde más lento de lo esperado y provoca un timeout.
• Una configuración local funciona, pero el ambiente de pruebas usa otra URL, puerto o credencial.
• Un módulo interpreta una fecha, un importe o un estado de manera diferente a otro módulo.
• Una operación guarda datos, pero otro componente no puede leerlos por un problema de formato o permisos.

Las pruebas de integración buscan exponer este tipo de fallas antes de que afecten flujos más grandes o lleguen al usuario final.

1.4 Ubicación dentro de los niveles de prueba

Para entender mejor este tipo de pruebas, conviene ubicarlas entre otros niveles de testing:

Las pruebas de integración no reemplazan a las pruebas unitarias ni a las pruebas end-to-end. Cada nivel observa el sistema desde una distancia distinta y aporta información diferente.

1.5 Qué se integra en una aplicación

Una integración puede aparecer en muchos lugares. No siempre significa conectar sistemas enormes; a veces es simplemente comprobar que dos capas internas de una aplicación se entienden correctamente.

Algunos ejemplos de integraciones son:

• Capa de negocio y base de datos: guardar, modificar, consultar y eliminar información.
• Controlador y servicio: recibir una petición, validar datos y ejecutar una operación.
• Servicio interno y API externa: enviar una solicitud y procesar la respuesta.
• Aplicación y sistema de archivos: generar, leer o importar archivos.
• Servicio y cola de mensajes: publicar eventos y verificar que otro proceso los consuma.
• Módulo de autenticación y módulo de permisos: identificar al usuario y determinar qué puede hacer.

1.6 Ejemplo cotidiano: registrar una compra

Imaginemos una aplicación de comercio electrónico. Cuando un cliente confirma una compra, pueden intervenir varios componentes:

• El controlador recibe la solicitud del usuario.
• El servicio de compras valida los productos y calcula el total.
• El repositorio consulta y actualiza la base de datos.
• El módulo de stock descuenta las unidades vendidas.
• El módulo de pagos solicita autorización a un proveedor externo.
• El sistema de notificaciones envía un correo de confirmación.

Una prueba unitaria puede verificar el cálculo del total. Pero una prueba de integración puede comprobar que, al confirmar una compra válida, se cree la orden, se actualice el stock y se registre el pago con los datos correctos.

1.7 Qué verifican las pruebas de integración

Según el sistema, una prueba de integración puede verificar distintos aspectos:

• Comunicación: que un componente pueda llamar a otro sin errores de conexión.
• Datos enviados: que la información llegue completa y con el formato esperado.
• Datos recibidos: que la respuesta sea interpretada correctamente.
• Persistencia: que los cambios se guarden y se puedan consultar después.
• Reglas compartidas: que varios módulos apliquen las mismas reglas de negocio.
• Manejo de errores: que el sistema responda bien ante respuestas inválidas, datos faltantes o fallas temporales.
• Configuración: que URLs, credenciales, variables de entorno y recursos apunten al lugar correcto.

1.8 Qué no son las pruebas de integración

También es importante aclarar algunos límites para no confundir este nivel de prueba con otros:

• No son pruebas unitarias grandes: deben enfocarse en la interacción entre componentes, no en todos los detalles internos de una función.
• No son necesariamente pruebas de interfaz gráfica: pueden ejecutarse sin abrir una pantalla, desde código o desde una herramienta de pruebas.
• No siempre prueban el sistema completo: pueden cubrir solo dos o tres componentes conectados.
• No deben depender de datos desordenados o ambientes inestables, porque eso vuelve difícil interpretar los resultados.
• No tienen que cubrir todos los caminos posibles; deben concentrarse en integraciones relevantes y riesgosas.

1.9 Alcance de una prueba de integración

El alcance define qué componentes participan en la prueba y cuáles quedan fuera. Esta decisión es importante porque afecta la velocidad, la estabilidad y la utilidad del resultado.

Por ejemplo, una prueba puede incluir:

• Un servicio real y una base de datos de prueba.
• Un controlador real, un servicio real y un repositorio real.
• Dos microservicios comunicándose en un ambiente controlado.
• Un proceso que escribe un archivo y otro proceso que lo lee.
• Un componente real conectado a un servicio externo simulado.

No existe un único alcance correcto para todos los casos. La elección depende del riesgo que se quiere cubrir y del costo de ejecutar la prueba.

1.10 Componentes reales y componentes simulados

En una prueba de integración, algunas dependencias pueden ser reales y otras simuladas. Por ejemplo, podemos probar un servicio real contra una base de datos real de pruebas, pero simular el proveedor de pagos para no hacer operaciones externas verdaderas.

La decisión debe ser consciente:

• Usar componentes reales aumenta la confianza, porque la prueba se parece más al comportamiento del sistema.
• Simular una dependencia puede hacer la prueba más rápida, controlable y segura.
• Depender de servicios externos reales puede volver la prueba lenta, costosa o inestable.
• Simular demasiado puede convertir la prueba en algo poco representativo.

En temas posteriores estudiaremos con más detalle cuándo conviene usar stubs, fakes, servicios simulados o dependencias reales.

1.11 Diferencia con una prueba unitaria

La diferencia principal está en el foco. Una prueba unitaria intenta aislar una unidad pequeña para comprobar su lógica. Una prueba de integración permite que varias partes interactúen para verificar el resultado conjunto.

1.12 Beneficios principales

Las pruebas de integración aportan varios beneficios al equipo:

• Detectan defectos que no aparecen cuando se prueban componentes aislados.
• Dan confianza sobre las conexiones importantes del sistema.
• Ayudan a validar contratos entre módulos y servicios.
• Permiten descubrir problemas de configuración antes de llegar a producción.
• Reducen el riesgo de que una funcionalidad falle cuando se ejecuta en un ambiente realista.
• Sirven como documentación práctica de cómo colaboran las partes del sistema.

1.13 Limitaciones y cuidados

Las pruebas de integración son muy útiles, pero también tienen desafíos:

• Pueden ser más lentas que las pruebas unitarias.
• Requieren preparar datos, ambientes y dependencias.
• Si fallan, a veces cuesta más identificar la causa exacta.
• Pueden volverse frágiles si dependen de horarios, datos compartidos o servicios inestables.
• Necesitan una estrategia de limpieza para no dejar estados que afecten otras pruebas.

Por eso no alcanza con escribir muchas pruebas de integración. Es necesario diseñarlas bien, mantenerlas claras y ejecutarlas en ambientes controlados.

1.14 Quién escribe y ejecuta estas pruebas

Las pruebas de integración pueden ser diseñadas por testers, desarrolladores o ambos roles trabajando juntos. En muchos equipos, los desarrolladores escriben las pruebas técnicas que conectan capas internas, mientras que QA ayuda a identificar escenarios, riesgos y datos relevantes.

Lo importante es que el equipo tenga una comprensión compartida de las interfaces entre componentes. Una prueba de integración útil no solo ejecuta código: expresa una expectativa clara sobre cómo deben colaborar las partes del sistema.

1.15 Qué debes recordar de este tema

• Las pruebas de integración verifican la colaboración entre dos o más componentes.
• Buscan errores de comunicación, datos, configuración, persistencia y coordinación.
• Están entre las pruebas unitarias y las pruebas de sistema o end-to-end.
• No siempre usan todo el sistema completo; su alcance debe definirse con claridad.
• Pueden combinar componentes reales con dependencias simuladas cuando tiene sentido.
• Son especialmente valiosas para detectar fallas que aparecen al conectar partes que individualmente parecen correctas.

1.16 Conclusión

Las pruebas de integración responden una pregunta fundamental: ¿las partes del sistema funcionan correctamente cuando se conectan entre sí?

Este tipo de prueba ayuda a pasar de la confianza en piezas aisladas a la confianza en colaboraciones reales. A medida que un sistema crece, las integraciones se vuelven puntos críticos porque concentran acuerdos, formatos, configuraciones, tiempos de respuesta y reglas compartidas.

En los próximos temas profundizaremos en los objetivos de las pruebas de integración, las estrategias para organizar el proceso, la preparación de ambientes y datos, y los distintos tipos de dependencias que suelen aparecer en sistemas reales.