Mockear un servicio que no controlas
El caso es siempre el mismo: tu flujo pasa por un servicio que no es tuyo, y no puedes llegar a él. No tienes VPN hoy, está caído, lo mantiene otro equipo, o directamente todavía no existe. Un mock desbloquea la tarde — y también es la forma más fácil de pasarte una semana probando contra una mentira.
Primero: ¿es un mock lo que necesitas?
La pregunta que decide no es «¿puedo llegar a ese servicio?», sino «¿estoy probando su respuesta o la estoy atravesando?».
| Situación | Qué usar | Por qué |
|---|---|---|
| Necesitas que devuelva algo para que tu flujo siga | Mock | Su contenido no es lo que verificas; es una precondición |
| Estás comprobando cómo reacciona tu código a lo que devuelve | El servicio real | Un stub te dirá que todo va bien, y no lo sabrás |
| Persigues un fallo que solo aparece contra lo de verdad | El entorno compartido | El fallo vive en la diferencia entre el stub y el original |
| Es un test de integración | Testcontainers o un doble en el test | El ciclo de vida lo gobierna el test, no tú |
| El servicio todavía no existe | Mock desde su contrato | Es el caso donde el mock no puede mentir: es la única fuente |
El riesgo que nadie cuenta: el stub se queda quieto
Un mock congela un contrato. El servicio real sigue cambiando, y tu stub no se entera: campos nuevos que no devuelves, un código de error que ahora significa otra cosa, un formato de fecha que cambió. Tu código pasa en local y falla al integrar, que es exactamente el problema que el mock prometía evitar.
Dos cosas lo reducen mucho, y ninguna es «tener cuidado»:
- Genera el stub desde el contrato, no de memoria. Si hay un OpenAPI, el esqueleto de la respuesta sale de ahí y se regenera cuando el contrato cambia.
- Captura llamadas reales el día que sí tienes acceso, y conviértelas en stubs. Un ejemplo capturado no se inventa nada.
Las cuatro formas de montarlo
| Forma | Coste de entrada | Dónde se rompe |
|---|---|---|
| Un servidor de stubs (WireMock, MockServer) en tu compose | Un contenedor más y sus ficheros de mapeo | Hay que redirigir a él la URL de quien llama, en la configuración de un repositorio ajeno |
| Un servicio falso escrito a mano | Media hora, y ya está | Se convierte en un proyecto que nadie mantiene y que nadie sabe de quién es |
| Interceptar en el cliente HTTP del propio servicio | Poco, si el framework lo permite | Es código de mentira dentro de tu repositorio, y alguien lo comiteará |
| Un mock integrado en el orquestador | Instalar la herramienta | Ata el entorno local a esa herramienta |
Fíjate en que tres de las cuatro comparten el mismo punto de dolor, y no es escribir el stub: es hacer que quien llama vaya al stub. Eso significa cambiar una URL en la configuración de un repositorio que a menudo no es tuyo, y deshacerlo cuando quieras volver al servicio real.
Cómo lo hace Aseptic
Aseptic trata «a dónde llama esta dependencia» como una decisión de primera clase, no
como una edición de fichero. Para cada dependencia eliges entre tres destinos —el
servicio local, tu entorno en la nube o un mock— y el motor
reescribe la URL al arrancar, inyectándola como propiedad
-D o variable de entorno.
Consecuencias prácticas:
- El repositorio no se toca. Nada que comitear, nada que revertir, nada que revisar en un pull request.
- Volver atrás es cambiar el destino, no deshacer una edición. Puedes ir y venir entre mock y servicio real varias veces en una tarde.
- El resto del escenario se entera solo: la decisión se toma una vez y la aplican todos los que llaman a ese servicio.
Los stubs se definen en el Mock Studio: capturar una llamada y convertirla en stub de un clic, generar el esqueleto de la respuesta desde un OpenAPI, y organizar variantes por servicio —la respuesta feliz, la que da 404, la que tarda— con recarga en caliente, sin reiniciar nada.
Lo que un mock no te va a dar
Conviene decirlo aquí, porque es donde se pierde el tiempo: si el fallo que persigues vive en el servicio real —una cabecera que añade la pasarela, un payload que nadie documentó, el comportamiento bajo carga— el mock no lo va a reproducir por definición. Ahí lo que hace falta es llegar al entorno compartido, y si tu sistema es demasiado grande para tu máquina, la comparación con Telepresence explica el otro enfoque.
Los pasos concretos están en mockear una dependencia, y si lo que te bloquea es que hay que levantar demasiadas cosas, la página de levantar solo parte del sistema.
Preguntas frecuentes
¿Cuándo conviene mockear un servicio y cuándo no?
Mockéalo cuando su respuesta no es lo que estás probando: la necesitas para que tu flujo avance, no para verificarla. No lo mockees cuando lo que quieres comprobar es precisamente cómo reacciona tu código a lo que ese servicio devuelve de verdad —ahí un stub te dirá que todo va bien y no será cierto—.
¿Un mock no acaba mintiéndome?
Puede, y es su riesgo real: el stub congela un contrato que al otro lado sigue cambiando. Se mitiga generándolo desde el OpenAPI del servicio en vez de a mano, y capturando llamadas reales cuando puedas llegar a él.
¿Cómo cambio entre el servicio real y el mock sin editar mis repositorios?
Con Aseptic es una decisión por dependencia: eliges local, nube o mock y la URL se reescribe al arrancar, inyectada como configuración. El fichero del repositorio se queda como está en git.
¿Necesito escribir el stub a mano?
No necesariamente. Se puede generar el esqueleto de la respuesta desde un OpenAPI, o capturar una llamada real la única vez que tuviste acceso y convertirla en stub de un clic.