En una prueba de integración no siempre usamos todas las dependencias reales. A veces necesitamos reemplazar una dependencia por una versión controlada para evitar costos, reducir inestabilidad, simular errores o probar un escenario difícil de producir con el sistema real.
Estos reemplazos se conocen como dobles de prueba. En este tema nos enfocaremos en tres formas habituales dentro de pruebas de integración: stubs, fakes y servicios simulados.
El objetivo no es memorizar nombres, sino entender cuándo conviene reemplazar una dependencia y qué riesgos aparecen al hacerlo.
Un doble de prueba es un componente que reemplaza a una dependencia real durante una prueba. Su función es permitir que el sistema bajo prueba avance sin usar la dependencia verdadera.
En integración, puede reemplazar:
Usar componentes reales aumenta el realismo, pero no siempre es práctico. Los dobles de prueba pueden ser útiles cuando una dependencia real:
El doble permite controlar respuestas y condiciones para enfocar la prueba en una integración concreta.
Un stub es un reemplazo simple que devuelve respuestas predefinidas. No intenta comportarse como un sistema completo; solo responde lo necesario para el caso de prueba.
Ejemplos:
Los stubs son útiles para pruebas simples y controladas, pero pueden volverse poco realistas si no respetan el contrato real.
Un fake es una implementación funcional simplificada de una dependencia. A diferencia de un stub, suele tener algo de comportamiento interno.
Ejemplos:
Un fake puede ser más flexible que un stub, pero también requiere mantenimiento para no alejarse demasiado del comportamiento real.
Un servicio simulado reemplaza a un servicio real y responde a llamadas como si fuera ese servicio. Puede ejecutarse como un proceso local, un servidor HTTP de prueba o una herramienta específica de simulación.
Puede simular:
Es especialmente útil para probar integraciones con APIs externas o servicios internos que no queremos levantar en cada ejecución.
La siguiente tabla resume las diferencias:
| Tipo | Idea principal | Ejemplo |
|---|---|---|
| Stub | Respuesta fija o muy simple. | Pago siempre aprobado. |
| Fake | Implementación simplificada con comportamiento. | Repositorio en memoria que guarda registros. |
| Servicio simulado | Servicio de prueba que imita una dependencia. | API falsa de pagos con escenarios configurables. |
Los dobles de prueba pueden aportar varias ventajas:
Estas ventajas son valiosas, siempre que el doble represente bien el aspecto del contrato que la prueba necesita.
El principal riesgo es obtener una falsa confianza. Si el doble se comporta de forma distinta al sistema real, la prueba puede pasar aunque la integración real falle.
Riesgos comunes:
Por eso cada doble debe tener un propósito claro y mantenerse alineado con la dependencia que reemplaza.
Un stub conviene cuando necesitamos una respuesta simple y estable para avanzar en el escenario.
Ejemplos:
Si el comportamiento de la dependencia es complejo, un stub puede ser insuficiente.
Un fake conviene cuando necesitamos una dependencia que tenga comportamiento, pero sin usar el recurso real.
Ejemplos:
El fake debe comportarse de manera suficientemente parecida para el riesgo que se quiere cubrir.
Un servicio simulado conviene cuando la dependencia se comunica por red, protocolo o API y necesitamos probar solicitudes y respuestas.
Casos típicos:
El servicio simulado debe validar que la solicitud recibida tenga la forma esperada, no solo devolver respuestas automáticas.
Para que un doble sea útil, debe reflejar el contrato relevante de la dependencia real.
Buenas prácticas:
Un doble desactualizado puede ser peor que no tener prueba, porque genera confianza equivocada.
Supongamos una integración con un proveedor de pagos. Un servicio simulado podría responder distintos escenarios:
| Escenario | Respuesta simulada | Qué verifica la prueba |
|---|---|---|
| Pago aprobado | Estado aprobado e identificador de transacción. | La orden queda pagada. |
| Pago rechazado | Estado rechazado y código de motivo. | La orden no queda confirmada. |
| Timeout | Demora mayor al máximo configurado. | El sistema maneja la espera de forma controlada. |
| Respuesta inválida | Falta un campo obligatorio. | El sistema detecta contrato inesperado. |
Para probar una integración con correo, no siempre queremos enviar mensajes reales. Un fake de correo puede guardar los mensajes en memoria o en una carpeta de prueba.
La prueba puede verificar:
Este fake permite verificar la colaboración sin contactar usuarios reales.
Al usar dobles de prueba en integración, suelen aparecer errores como:
Antes de usar un doble en una prueba de integración, conviene preguntar:
Los dobles de prueba son herramientas útiles para diseñar pruebas de integración prácticas, rápidas y controladas. Permiten simular situaciones difíciles, evitar efectos reales y trabajar aunque una dependencia no esté disponible.
Pero deben usarse con criterio. Una prueba que reemplaza demasiadas dependencias puede dejar de verificar la integración que importa. El equilibrio está en usar dobles para controlar lo que queda fuera del objetivo, sin ocultar el riesgo principal.
En el próximo tema veremos cuándo usar componentes reales y cuándo simular dependencias.