Una de las decisiones más importantes al diseñar una prueba de integración es definir su alcance. Es decir: qué componentes participarán en la prueba, qué dependencias serán reales, qué dependencias se reemplazarán y qué resultado se observará.
Si incluimos muy pocas partes, la prueba puede parecerse demasiado a una prueba unitaria y aportar poca confianza sobre la integración. Si incluimos demasiadas, puede volverse lenta, frágil y difícil de diagnosticar.
En este tema aprenderemos a reconocer los límites del sistema para decidir qué incluir y qué dejar fuera de una prueba de integración.
Definir un límite significa marcar hasta dónde llega la prueba. Dentro del límite quedan los componentes reales que queremos verificar trabajando juntos. Fuera del límite quedan dependencias que no se probarán en ese caso o que se reemplazarán por dobles de prueba, configuraciones controladas o servicios simulados.
Por ejemplo, si probamos la integración entre servicio de usuarios y base de datos, el proveedor externo de correo puede quedar fuera del límite y reemplazarse por una simulación.
El alcance afecta directamente la utilidad de la prueba. Una prueba de integración debe equilibrar confianza, velocidad, estabilidad y facilidad de diagnóstico.
Un alcance bien definido permite:
Cuando el alcance es confuso, una prueba puede fallar por causas que no pertenecen al objetivo que queríamos validar.
En una prueba de integración se suelen incluir componentes cuya colaboración queremos verificar. Algunos ejemplos son:
La decisión debe partir de la pregunta: ¿qué colaboración queremos comprobar en este caso?
No todas las dependencias deben participar en cada prueba de integración. Algunas pueden quedar fuera porque no son el objetivo de la prueba, porque son costosas, inestables o difíciles de controlar.
Ejemplos de dependencias que a veces se reemplazan:
Dejar una dependencia fuera no significa ignorarla para siempre. Significa que esa prueba concreta no tiene como objetivo verificarla.
Una prueba de integración puede combinar componentes reales con componentes simulados. Esto permite concentrarse en la colaboración que interesa sin depender de todo el sistema completo.
| Decisión | Ventaja | Riesgo |
|---|---|---|
| Usar dependencia real | Aumenta el realismo de la prueba. | Puede hacerla más lenta o inestable. |
| Simular dependencia | Permite controlar respuestas y errores. | Puede ocultar diferencias con el comportamiento real. |
| Usar base de datos de prueba | Verifica persistencia real sin afectar producción. | Requiere limpieza y preparación de datos. |
| Usar servicio externo real | Verifica la integración de punta a punta con ese proveedor. | Puede depender de red, costo, permisos y disponibilidad. |
Conviene incluir un componente real cuando su comportamiento es parte del riesgo que queremos cubrir. Algunas preguntas útiles son:
Si la respuesta a varias de estas preguntas es afirmativa, probablemente tenga sentido incluirlo.
Conviene dejar fuera o simular una dependencia cuando su participación no aporta valor suficiente para el objetivo de la prueba.
Puede ser razonable dejar fuera un componente cuando:
Esta decisión debe documentarse en la prueba o en la estrategia de testing para evitar falsas expectativas sobre lo que se está verificando.
A veces se piensa que una prueba de integración siempre debe cubrir capas completas o servicios completos. No necesariamente. El límite de la prueba depende del objetivo.
Por ejemplo, en una arquitectura con controlador, servicio, repositorio y base de datos, podemos tener distintas pruebas:
Todas pueden ser pruebas de integración, pero cada una tiene un alcance distinto.
Definir el límite también implica definir qué resultado vamos a observar. Una prueba de integración puede verificar:
Observar solo la respuesta puede ser insuficiente. Muchas integraciones producen efectos importantes que no se ven directamente en el valor devuelto.
Un alcance demasiado amplio puede convertir la prueba de integración en una prueba difícil de mantener. Conviene evitar:
Una prueba de integración debe ser suficientemente realista para detectar errores de colaboración, pero no tan amplia que pierda claridad.
Supongamos que queremos probar el registro de un usuario. Distintos límites generan distintas pruebas:
| Alcance | Qué incluye | Qué deja fuera |
|---|---|---|
| Servicio y base de datos | Servicio de usuarios, repositorio y base de datos de prueba. | Controlador, interfaz gráfica y correo. |
| Controlador a base de datos | Controlador, servicio, repositorio y base de datos. | Proveedor real de correo. |
| Registro con notificación simulada | Controlador, servicio, base de datos y servicio de correo simulado. | Envío real del correo. |
| Flujo completo real | Aplicación completa y proveedor de correo real. | Poco o nada dentro del flujo. |
El último caso puede parecer más completo, pero tal vez corresponda más a una prueba de sistema o end-to-end que a una prueba de integración cotidiana.
Si el límite es demasiado pequeño, la prueba puede perder valor como prueba de integración. Por ejemplo, si probamos un servicio simulando todas sus dependencias, quizá estemos verificando solo lógica interna y no integración real.
Señales de un límite demasiado pequeño:
En esos casos, tal vez la prueba sea válida, pero debería clasificarse como unitaria o de componente aislado, no como integración.
Si el límite es demasiado grande, la prueba puede convertirse en una prueba lenta y difícil de diagnosticar. Un fallo puede deberse a muchas causas posibles.
Señales de un límite demasiado grande:
En estos casos, conviene dividir el escenario en pruebas de integración más específicas y dejar los flujos completos para pruebas de sistema o end-to-end.
Una prueba clara debería expresar su alcance en el nombre, en la estructura o en la documentación. Por ejemplo:
Estos nombres indican qué colaboración se verifica y qué resultado importa. Eso ayuda a mantener la suite entendible a medida que crece.
Definir límites es una habilidad esencial para escribir buenas pruebas de integración. El valor de la prueba depende de incluir las partes correctas y dejar fuera aquello que no aporta al objetivo del caso.
Una prueba de integración útil no intenta probar todo. Prueba una colaboración concreta con suficiente realismo y con un resultado observable que permita detectar fallas importantes.
En el próximo tema veremos distintas estrategias de integración, como incremental, big bang, top-down y bottom-up.