En el tema anterior vimos que las pruebas de integración verifican si varios componentes de software colaboran correctamente. Ahora nos enfocaremos en una pregunta clave: ¿para qué hacemos pruebas de integración?
Responder esta pregunta ayuda a diseñar mejores pruebas. Si no tenemos claro el objetivo, podemos terminar escribiendo pruebas demasiado amplias, lentas, frágiles o repetidas. Una buena prueba de integración debe buscar información concreta sobre la relación entre componentes.
El objetivo general es reducir el riesgo de que el sistema falle cuando sus partes se conectan. Para lograrlo, las pruebas de integración observan comunicación, datos, contratos, configuración, persistencia, errores y comportamiento conjunto.
El objetivo principal de una prueba de integración es comprobar que las partes conectadas del sistema funcionen correctamente como conjunto.
Esto significa que la prueba no se limita a preguntar si una función individual devuelve un valor correcto. También verifica si ese valor se transmite bien, si otro componente lo interpreta correctamente y si el resultado final queda en el estado esperado.
Uno de los objetivos más importantes es comprobar que los componentes puedan comunicarse. En sistemas reales, la comunicación puede fallar por muchas razones:
Una prueba de integración bien diseñada debe revelar este tipo de problemas de forma clara. No alcanza con saber que “algo falló”; la evidencia debe ayudar a ubicar qué comunicación no funcionó y bajo qué condiciones.
Cuando dos componentes se conectan, existe un acuerdo entre ellos. Ese acuerdo puede ser formal, como una especificación de API, o informal, como una clase que espera recibir ciertos campos. A ese acuerdo lo llamamos contrato.
Una prueba de integración debe comprobar que ese contrato se respete:
Muchos errores de integración nacen cuando una parte del sistema cambia y otra parte sigue esperando el comportamiento anterior.
Otro objetivo central es comprobar que los datos viajen correctamente a través de los componentes. Un dato puede ser válido al comienzo, pero deformarse o perderse durante el recorrido.
Por ejemplo, en una operación de compra puede ser necesario verificar que:
La prueba de integración observa el recorrido completo dentro del alcance definido. Esto permite encontrar errores que no se ven si se prueba cada operación por separado.
Muchas integraciones incluyen una base de datos u otro mecanismo de almacenamiento. En esos casos, uno de los objetivos es verificar que el sistema pueda guardar información y luego recuperarla correctamente.
La prueba puede comprobar, por ejemplo:
Este objetivo es especialmente importante porque la persistencia suele ser compartida por varias funcionalidades. Un error en datos guardados puede afectar procesos posteriores.
Una aplicación puede funcionar en la computadora de un desarrollador y fallar en un ambiente de pruebas por diferencias de configuración. Las pruebas de integración ayudan a detectar esas diferencias.
Algunos elementos que conviene validar son:
Este objetivo no significa probar toda la infraestructura en profundidad. Significa confirmar que las dependencias necesarias para la integración están disponibles y configuradas de forma coherente.
Una integración no solo debe funcionar cuando todo sale bien. También debe comportarse de manera controlada cuando algo falla.
Las pruebas de integración pueden verificar respuestas ante situaciones como:
El objetivo es comprobar que el sistema no falle de forma descontrolada, que informe el problema con claridad y que mantenga un estado consistente.
En muchos sistemas, una regla de negocio no vive en un solo lugar. Puede involucrar validaciones en una capa, cálculos en otra, persistencia en otra y comunicación con otros servicios.
Por ejemplo, una regla puede indicar que un usuario no puede comprar más unidades que el stock disponible. Para integrarla correctamente, el sistema debe:
Una prueba de integración puede verificar que todas esas decisiones coordinadas se cumplan como una única conducta observable.
Las pruebas de integración permiten encontrar defectos antes de llegar a pruebas de sistema o end-to-end. Esto es valioso porque una prueba más amplia puede fallar por muchas razones y tardar más en diagnosticar el problema.
Si las integraciones principales ya fueron verificadas, las pruebas de niveles superiores parten de una base más confiable. Esto no elimina todos los errores, pero reduce el ruido y ayuda a que cada nivel de prueba cumpla mejor su función.
Otro objetivo importante es permitir que el equipo modifique el sistema con menor temor a romper conexiones existentes. Cuando una prueba de integración cubre una colaboración crítica, puede detectar regresiones después de cambios en código, consultas, configuraciones o contratos.
Por ejemplo, si se cambia la forma de calcular descuentos, una prueba de integración puede confirmar que el total actualizado sigue guardándose correctamente en la orden y que el módulo de facturación recibe el importe esperado.
Este objetivo es especialmente útil en sistemas que evolucionan con frecuencia, donde los componentes se modifican, se reemplazan o se conectan con nuevas dependencias.
Una prueba de integración también debe aportar evidencia útil cuando falla. El objetivo no es solo marcar una prueba como fallida, sino facilitar la investigación.
Una buena prueba ayuda a responder:
Cuanto más clara sea la prueba, menos tiempo necesitará el equipo para entender y corregir el defecto.
Un error común es intentar que una sola prueba de integración verifique demasiadas cosas. Eso puede hacer que la prueba sea difícil de mantener y que sus fallas sean confusas.
Conviene evitar que una misma prueba intente cubrir al mismo tiempo:
Una prueba de integración debe tener un propósito claro. Si una prueba falla, debería ser posible entender qué colaboración se estaba verificando.
Supongamos una funcionalidad para registrar un nuevo usuario. Algunos objetivos de integración podrían ser:
| Objetivo | Qué se verifica |
|---|---|
| Guardar usuario | El controlador, el servicio y el repositorio crean el registro esperado en la base de datos. |
| Evitar duplicados | Si el correo ya existe, la operación se rechaza y no se crea otro usuario. |
| Enviar notificación | Después del registro correcto, se solicita el envío del mensaje de bienvenida. |
| Manejar error externo | Si el servicio de notificaciones falla, el sistema responde de forma controlada. |
Cada objetivo puede convertirse en una prueba o en un pequeño grupo de pruebas. Lo importante es que cada una tenga un propósito verificable.
Las pruebas de integración no se escriben solamente para aumentar la cantidad de pruebas de un proyecto. Se escriben para obtener confianza sobre puntos concretos donde varios componentes deben colaborar.
Cuando sus objetivos están bien definidos, estas pruebas ayudan a encontrar defectos importantes, documentan acuerdos entre partes del sistema y permiten que el equipo evolucione el software con mayor seguridad.
En el próximo tema compararemos con más detalle las pruebas unitarias, de integración, de sistema y end-to-end para entender qué aporta cada nivel y cómo se complementan.