Una decisión central en pruebas de integración es elegir qué dependencias serán reales y cuáles serán simuladas. Esta decisión afecta la confianza, la velocidad, la estabilidad y la facilidad para diagnosticar fallas.
Usar todo real puede parecer ideal, pero no siempre es práctico. Simular todo puede ser rápido, pero puede ocultar errores de integración importantes. El objetivo es encontrar un equilibrio razonable según el riesgo que se quiere cubrir.
En este tema veremos criterios para decidir cuándo usar componentes reales y cuándo reemplazar dependencias por stubs, fakes o servicios simulados.
Antes de decidir, conviene formular una pregunta concreta:
Si una dependencia es parte del riesgo que queremos cubrir, probablemente convenga usarla de forma real o muy representativa. Si no forma parte del objetivo, puede ser razonable simularla para mantener la prueba controlada.
Usar componentes reales aumenta el realismo de la prueba. Permite detectar errores que una simulación podría ocultar.
Ventajas:
Por ejemplo, probar un repositorio contra una base de datos real de prueba puede detectar errores de SQL, migraciones o restricciones que un fake no mostraría.
El realismo tiene costo. Usar dependencias reales puede volver la prueba más lenta o frágil.
Riesgos:
Una prueba que falla por una dependencia que no era el objetivo puede generar ruido y pérdida de confianza en la suite.
Simular dependencias permite controlar mejor el escenario de prueba. Esto es útil cuando necesitamos respuestas específicas, errores concretos o condiciones difíciles de provocar.
Ventajas:
Por ejemplo, simular una pasarela de pagos permite probar pagos aprobados, rechazados y timeouts sin realizar operaciones reales.
El principal riesgo de simular es que la simulación no represente bien el comportamiento real. Entonces la prueba puede pasar aunque la integración real falle.
Riesgos:
Simular no es un problema en sí. El problema es simular sin mantener el doble alineado con el riesgo real.
El objetivo de la prueba debe guiar la decisión.
Ejemplos:
Una dependencia real aporta valor cuando participa directamente en la colaboración que estamos verificando.
Si una dependencia es fuente frecuente de errores o tiene impacto alto, conviene probarla con más realismo.
Señales de dependencia riesgosa:
Cuanto mayor es el riesgo, más cuidado debemos tener al decidir simular.
Una dependencia inestable puede hacer que las pruebas fallen sin cambios en el código. Si eso ocurre con frecuencia, el equipo puede dejar de confiar en la suite.
Puede convenir simular cuando:
También puede ser útil tener pocas pruebas con la dependencia real y más pruebas con simulación controlada.
Algunas dependencias tienen costos o efectos reales. En esos casos, simular puede ser la decisión más segura para pruebas frecuentes.
Ejemplos:
Si se usa un servicio real, debe ser en ambiente de prueba o sandbox y con datos controlados.
Una prueba debe ayudar a encontrar la causa cuando falla. Si se incluyen demasiadas dependencias reales, el diagnóstico puede volverse lento.
Conviene simular una dependencia cuando:
Un buen alcance hace que una falla señale con claridad qué integración se rompió.
Las pruebas de integración deben aportar confianza, pero también deben poder ejecutarse con una frecuencia razonable. Si una suite tarda demasiado, el equipo la ejecutará menos.
Puede ser útil organizar pruebas en grupos:
No todas las pruebas tienen que ejecutarse con la misma frecuencia.
La siguiente tabla muestra decisiones habituales:
| Dependencia | Usar real cuando... | Simular cuando... |
|---|---|---|
| Base de datos | Se prueba persistencia, consultas o transacciones. | El objetivo no depende del almacenamiento real. |
| API externa | Se valida contrato real en sandbox. | Se prueban errores, timeouts o casos frecuentes localmente. |
| Correo | Se valida configuración real de envío en ambiente controlado. | Solo se necesita verificar que se solicitó el envío correcto. |
| Cola | Se prueba publicación y consumo real. | Solo se necesita verificar que se intenta publicar un evento. |
| Servicio interno | El contrato y comportamiento real son parte del riesgo. | El servicio no está disponible o no es el foco del caso. |
En proyectos reales, lo más común es usar una estrategia mixta. Algunas pruebas usan dependencias reales y otras usan simulaciones.
Por ejemplo, para compras:
Esta combinación permite cubrir riesgos importantes sin volver todas las pruebas lentas o frágiles.
La prueba debe dejar claro qué componentes son reales y cuáles están simulados. Esto evita interpretar mal su cobertura.
Conviene documentar:
Una prueba clara no promete más de lo que realmente verifica.
Para probar el registro de usuario, podríamos tomar estas decisiones:
| Componente | Decisión | Motivo |
|---|---|---|
| Controlador | Real | Queremos validar entrada y respuesta. |
| Servicio de usuarios | Real | Contiene la regla de registro. |
| Base de datos | Real de prueba | Queremos verificar persistencia y duplicados. |
| Correo | Fake | Queremos verificar solicitud de envío sin mandar correo real. |
Al decidir entre componentes reales y simulados, suelen aparecer errores como:
Antes de decidir, conviene revisar:
Decidir entre componentes reales y dependencias simuladas es una cuestión de equilibrio. Una buena prueba de integración debe ser lo bastante realista para detectar errores importantes y lo bastante controlada para ser repetible y diagnosticable.
El criterio principal siempre debe ser el objetivo de la prueba: qué colaboración queremos verificar y qué dependencias forman parte de ese riesgo.
En el próximo tema veremos cómo diseñar casos de prueba de integración.