Sección Mocks

La sección Mocks es donde defines las respuestas simuladas que Aseptic sirve cuando una dependencia se resuelve como mock. Te permite trabajar sin VPN y sin levantar el core al que llama tu micro.

No necesitas iniciar nada para editar mocks: el catálogo vive en disco (.aseptic/mocks/<servicio>.json) y se sirve con recarga en caliente, así que un cambio se aplica al instante aunque el escenario esté corriendo.

El árbol: servicios → endpoints

El lateral muestra un árbol de servicios (los cores mockeables) y, dentro de cada uno, sus endpoints. Los endpoints se agrupan en carpetas plegables derivadas de los segmentos de su ruta, sin que tengas que organizarlos a mano.

Un servicio es mockeable si es una dependencia de algún micro (o si creas su fichero en .aseptic/mocks). Puedes mostrar u ocultar los servicios que aún no tienen stubs.

Crear un stub

Pulsa Nuevo stub (o el menú «⋮») y elige el servicio destino —uno del catálogo o uno nuevo que se crea al guardar—. Un endpoint se define con:

Método y ruta (relativa a la ruta base del servicio).
Una o varias variantes de respuesta.

Hay dos formas de rellenar el cuerpo:

Desde OpenAPI: si el servicio declara una especificación OpenAPI (en el manifiesto del micro, o derivada de su URL de nube), selecciona la operación y Aseptic genera una plantilla del cuerpo.
Manual: si no hay OpenAPI, escribes el cuerpo JSON a mano.

Variantes: la unidad de trabajo

Un endpoint puede tener varias variantes (por ejemplo una 200 y una 500). Cada variante tiene su etiqueta, código de estado, cuerpo (JSON), cabeceras y una latencia opcional en milisegundos para simular lentitud.

La variante seleccionada se expande en línea con su cuerpo, cabeceras y ajustes juntos. Sobre el cuerpo hay tres botones: Formatear lo sangra (y guarda ese sangrado), Rellenar plantilla lo genera desde el OpenAPI y Ver con formato lo abre en un visor grande, que no edita nada y sirve para leer una respuesta que no cabe en el recuadro. La variante que se sirve se marca aparte con un conmutador (es independiente de la que estés editando): es la respuesta que Aseptic devolverá a quien llame a ese endpoint.

Puedes duplicar una variante para partir de una parecida, y activar o desactivar un endpoint entero (uno desactivado no se sirve ni se edita).

Reglas: responder según la petición

Encima de las variantes hay un bloque Reglas. Cada regla dice «cuando se cumplan estas condiciones, sirve esta variante», y se evalúan en orden: gana la primera que casa. Si no casa ninguna, se sirve la variante activa — así que un endpoint sin reglas se comporta igual que siempre. La última fila del bloque, fija, recuerda justo eso.

Una condición mira un dato de la petición, sin sintaxis que aprender:

query o cabecera, por su nombre;
cuerpo, por una ruta con puntos (pedido.cliente.tipo); un número entra en una lista (pedido.lineas.0.sku).

Y compara con es igual a, es distinto de, existe o no existe. Las condiciones de una misma regla se cumplen todas a la vez; para un «o» se añade una segunda regla, que es para lo que la lista está ordenada. El orden se cambia con las flechas de cada regla: mover una regla es cambiar su prioridad.

La regla apunta a la variante por su etiqueta, no por su posición, para que reordenar variantes no cambie en silencio lo que sirve. Por eso, en un endpoint con reglas, dos variantes no pueden llamarse igual. Si renombras una variante a la que apuntaba una regla, la regla se marca en atención y deja de servirse hasta que la corrijas.

Probar simula una petición ahí mismo —query, cabeceras y cuerpo— y dice qué variante saldría y qué regla la eligió. No hace falta tener el escenario en marcha. Y cuando sí lo está, el dock de Llamadas mock marca cada llamada con la regla que la decidió, así que dos llamadas iguales con respuestas distintas se explican solas.

Desde la terminal es lo mismo: aseptic mock probe POST "/v1/pedidos?tipo=premium", con -H 'X-Vip: 1' para las cabeceras y -d '{...}' para el cuerpo.

Guardado automático

El editor de mocks guarda solo, con un pequeño retardo, mientras escribes; verás un indicador «Guardado». Salvaguardas:

Solo se persisten estados válidos: un cuerpo JSON a medias no rompe el mock servido —se mantiene el último válido en disco y el error se marca en línea—.
Un stub nuevo no se persiste hasta tener método y ruta usables.
El borrado siempre es explícito, con confirmación.

Mock Studio: de una llamada real a un stub

Cuando un escenario corre y un micro llama a un mock que aún no tiene respuesta, esa llamada aparece en el dock Llamadas mock. Desde ahí puedes crear un stub con un clic a partir de la llamada observada: vas directo al endpoint que quieres completar, sin buscarlo. También puedes probar qué respondería el mock sin arrancar nada.

Llamada real: capturar la respuesta del servicio

A veces no quieres inventarte el cuerpo: quieres el que devuelve el servicio de verdad. Cada endpoint tiene un conmutador Llamada real. Mientras esté puesto, ese endpoint deja de servir su variante: la petición sale al servicio real, su respuesta se devuelve tal cual a quien llamó y se graba como variante «Real» con su código, que queda activa. Al quitarlo, el mock responde lo último que dijo el servicio, ya sin salir a la red.

A dónde llama: al micro del escenario si está en marcha, y si no a la URL de nube de la dependencia. El icono «i» del conmutador dice el destino exacto; si el servicio no tiene ninguno, el conmutador queda apagado y explica por qué.
Verbos que cambian datos: encenderlo sobre un POST, un PUT o un DELETE pide confirmación diciendo el destino. No está prohibido —capturar la respuesta de un alta es un caso legítimo—, pero se ejecuta de verdad allí.
Una variante por código: Real 200, Real 404… Capturar mil llamadas no crea mil variantes; refresca la del código que llegue.
Lo que no sea texto (una imagen, un PDF) o pase de 1 MB se sirve pero no se graba.

Los endpoints en captura se marcan con la etiqueta real en el árbol, para que no se te quede uno saliendo a la red sin darte cuenta.

Importar y exportar

Con los iconos de importar/exportar del panel:

Exportar los endpoints de un servicio (o de varios) a un fichero JSON.
Importar un JSON propio o una colección Postman (sus carpetas se mapean a servicios).

Es útil para compartir un catálogo de mocks o reutilizarlo entre escenarios.

Lo mismo desde el CLI

Todo esto existe también en el CLI: aseptic mock services, mock catalog, mock save, mock set-active, mock skeleton, mock from-call, mock probe, mock capture, mock import / export. Ver la referencia del CLI.