Saltar a los pasos

Tu primer mock en 10 minutos

Una guía de Mockix para empezar desde cero: instalarlo, encender el ejemplo, probarlo en el navegador y crear el mock de tu propia API.

¿Qué es un mock?

Tu app le pide datos a una API
Cuando una app muestra productos, le pide la información a una API: un servidor que responde con datos. A veces esa API todavía no existe, está caída o no conviene tocar la de verdad mientras pruebas.
Un mock responde en su lugar
Es una API de mentiras que contesta lo que tú decides. Tu app le habla igual que a la real y no nota la diferencia.
Mockix los crea en tu equipo
Sin servidores ni cuentas: los mocks corren en tu computadora y se guardan como archivos en una carpeta tuya.

Instala y crea el ejemplo

  1. Descarga el instalador desde la página de Mockix y ábrelo. Si Windows muestra «Windows protegió tu PC», elige «Más información» y «Ejecutar de todas formas»: aparece porque el instalador aún no está firmado.
  2. Abre Mockix y pulsa Crear el ejemplo….
  3. Elige una carpeta vacía, por ejemplo Documentos\mi-primer-mock.

Mockix crea ahí un mock llamado tienda: la API de una tienda de café con productos, pedidos e inventario.

Mockix al abrirlo por primera vez: los botones Abrir carpeta y Crear el ejemplo, y a la derecha cómo se organiza un workspace

Enciéndelo y pruébalo

  1. En la barra de la izquierda, haz clic en tienda y pulsa Iniciar. El estado cambia a «En marcha» y aparece su dirección.
  2. Abre esta dirección en tu navegador: http://127.0.0.1:3000/v1/productos/prd_7Qm2
{
  "id": "prd_7Qm2",
  "nombre": "Café de Veracruz 500 g",
  "precio": 189,
  "moneda": "MXN",
  "activo": true
}

Prueba también /v1/productos, que da la lista, y /v1/productos/999, que responde un error 404. Cada petición aparece en el Log en vivo con lo que respondió y cuánto tardó.

El mock tienda en marcha en http://127.0.0.1:3000/v1, con sus rutas y el log en vivo de tres peticiones: la lista, un 404 y un producto

Cambia una respuesta

  1. En la barra de la izquierda, dentro de productos, abre la ruta GET /productos/:id.
  2. En la respuesta ok, cambia "activo": true por "activo": false.
  3. Pulsa Guardar o Ctrl S y recarga el navegador.

La respuesta ya dice false. Mockix aplica cada cambio al momento, sin reiniciar nada. El :id de la ruta es la parte que cambia en cada petición.

Editor de la ruta GET /productos/:id en Mockix, con la plantilla de la respuesta ok y la respuesta que dio el mock

Crea el mock desde tu contrato

  1. Pulsa Nuevo mock (en un workspace vacío, Crear mock desde un contrato) y deja elegida la opción Desde un contrato OpenAPI.
  2. Pulsa Elegir contrato… y elige el .yaml o .json de tu API. Mockix propone nombre, puerto y prefijo; cámbialos si quieres.
  3. Pulsa Crear mock, luego Iniciar, y cambia en tu app la dirección de la API por la del mock.

Del contrato salen las rutas con todas sus respuestas, el contrato conectado para revisar cada petición, datos con CRUD para los recursos que se listan y se leen por id, escenarios cuando hay un campo de estado con acciones que lo cambian, y tres perfiles de caos con sus errores, apagados. El informe dice qué creó y qué no pudo deducir.

Diálogo Nuevo mock de Mockix con la opción Desde un contrato OpenAPI: el archivo tienda.openapi.yaml elegido, nombre, puerto y prefijo propuestos, y las casillas para conectar el contrato y preparar perfiles de caos

Pide cualquier respuesta

Si el contrato documenta un 404 o un 500, el mock te lo da cuando lo pides, para probar cómo reacciona tu app a cada error:

  1. En el navegador, añade ?mockix_respuesta=404 a la dirección.
  2. Desde tu app o PowerShell, manda la cabecera X-Mockix-Respuesta: Invoke-RestMethod -Method Post http://127.0.0.1:3001/v1/pedidos -Headers @{ "X-Mockix-Respuesta" = "500" }

Sin eso responde la respuesta normal. Si tu contrato solo tiene acciones (todo POST), quedan las rutas con todas sus respuestas para elegir. Un Swagger 2.0 también se conecta: Mockix lo convierte a OpenAPI 3 y tu archivo no cambia.

¿Tienes una colección de Postman o Sendix, un HAR o un entorno de Mockoon? Usa el icono Importar. ¿Prefieres empezar de cero? En Nuevo mock elige Vacío.

Informe de Mockix tras crear el mock desde el contrato: el contrato conectado, cinco respuestas de error que se piden con X-Mockix-Respuesta, datos con CRUD, el escenario de pedidos deducido y los perfiles de caos preparados

Más funciones, paso a paso

Para acercarte a una API de verdad
Grabaciones, escenarios, perfiles de caos y contratos. Cada uno se abre desde los iconos de la columna izquierda de la ventana.
Con el ejemplo encendido
Todos los pasos usan el mock tienda, así que mantenlo en marcha mientras pruebas.

Grabaciones

Si la API real ya existe, Mockix la copia: se pone en medio, deja pasar tus peticiones, guarda lo que responde y lo convierte en un mock. Pruébalo grabando la propia tienda:

  1. Abre Grabaciones. Arriba verás localhost:4100 → https://; a la derecha de la flecha escribe http://127.0.0.1:3000/v1 y pulsa Grabar.
  2. Abre http://localhost:4100/productos/prd_7Qm2 y luego …/productos/prd_8Lx4. Usa el puerto 4100, el del intermediario.
  3. Pulsa Detener. En Rutas detectadas ya aparece GET /productos/:id. Ponle nombre y pulsa Convertir en mocks.

Con una API real pones su dirección en el paso 1 y en tu app usas http://localhost:4100 mientras grabas. Las contraseñas, tokens y cookies no pasan al mock.

Vista de grabaciones de Mockix: la ruta inferida GET /envios/:id, la petición grabada y el cuerpo que irá al mock sin credenciales

Escenarios

Una API real recuerda cosas: un pedido está «creado», al pagarlo pasa a «pagado» y luego a «enviado». Pruébalo con el pedido del ejemplo:

  1. Abre http://127.0.0.1:3000/v1/pedidos/ped_1: dice "estado": "creado".
  2. Págalo desde PowerShell, porque es un POST: Invoke-RestMethod -Method Post http://127.0.0.1:3000/v1/pedidos/ped_1/pago
  3. Ábrelo otra vez: "pagado". Espera 10 segundos: "enviado", con número de guía.
  4. Abre Escenarios: el diagrama marca el estado de ped_1 y qué lo hizo avanzar. Reiniciar instancias vuelve a empezar.
key: params.id        # un estado por cada pedido
initial: creado
states: [creado, pagado, enviado, entregado, cancelado]
transitions:
  - { from: creado, to: pagado, on: { method: POST, path: /pedidos/:id/pago } }
  - { from: pagado, to: enviado, after: 10s }

Es el archivo mocks/tienda/scenarios/pedido.yaml; la ruta GET /pedidos/:id responde según el estado.

Vista de escenarios de Mockix: diagrama de estados de un pedido con las instancias activas

Perfiles de caos

La red a veces va lenta o la API falla. Con un perfil de caos compruebas que tu app lo aguanta.

  1. Abre Perfiles de caos y elige red-3g, un celular lento. La gráfica muestra latencia y errores en el tiempo.
  2. En Dónde se aplica, elige red-3g en la lista del mock tienda.
  3. Abre …/v1/productos: tarda un tercio de segundo o más. Efectos aplicados dice qué recibió cada petición, como +391 ms.

Con red-inestable verás errores 500 y 503 a los 30 segundos. Arrastra los puntos de la curva y pulsa Aplicar cambios para hacer el tuyo; «sin caos» lo quita.

Perfil de caos de Mockix: curva de latencia y errores y la lista de efectos aplicados a cada petición

Contratos

Un contrato es la especificación oficial de tu API. Con él, Mockix revisa cada petición y te avisa si tu app manda algo que la API real rechazaría.

Cómo debe ser: un archivo OpenAPI 3.0 o 3.1 en la carpeta contracts/, con cada ruta, lo que recibe y lo que devuelve, con sus tipos y campos obligatorios. El prefijo va en servers y las rutas sin él. Si ya tienes tu API documentada en Swagger u OpenAPI, ese archivo sirve tal cual. Se conecta en el mock.yaml:

contract:
  file: contracts/tienda.openapi.yaml
  mode: warn     # off · warn: avisa · strict: responde 400
  1. El ejemplo ya lo trae. Manda un precio como texto: Invoke-RestMethod -Method Post http://127.0.0.1:3000/v1/productos -ContentType application/json -Body '{"nombre":"Taza","precio":"caro"}' (PowerShell lo muestra en rojo: es el error esperado).
  2. Abre Contratos: verás body.precio debe ser number (recibido "caro", un string).
  3. Cambia a Estricto y repite: responde un 400 «La petición no cumple el contrato».
Vista de contratos de Mockix: reglas rotas con la última petición que las rompió y el esquema esperado

Palabras que vas a ver

Workspace
La carpeta donde guardas tus mocks. Es la que abres en Mockix.
Mock
Una API de mentiras, con su dirección y su puerto.
Ruta
Una dirección del mock, como GET /productos/:id. Lo que va después de los dos puntos cambia en cada petición.
Respuesta
Lo que devuelve una ruta. Una ruta puede tener varias y elegir una según la petición, como el 404 para los productos que no existen.
Puerto
El número al final de la dirección, como 3000. Cada mock usa el suyo.

Si algo falla

«Esa carpeta es el mock «x», no un workspace»
Abriste una carpeta de más adentro. Abre la que indica el mensaje, la que contiene la carpeta mocks.
El mock queda «Con errores» y dice PORT_IN_USE
Otro programa usa el puerto 3000. Abre mocks\tienda\mock.yaml con el Bloc de notas, cambia port: 3000 por otro número, como 3001, guarda y pulsa Iniciar otra vez.
El navegador no puede conectar
El mock está apagado. Selecciónalo y pulsa Iniciar.
Quiero borrar un mock
Selecciónalo y pulsa Mover el mock a la papelera, debajo de sus datos. Se detiene y su carpeta va a la papelera de Windows, de donde la puedes recuperar.
Aparece «No route in this mock»
La dirección no coincide con ninguna ruta. Revisa que lleve el prefijo /v1 y que el método sea el correcto.

Ya tienes
tu primer mock

El manual de uso explica el resto: respuestas por reglas, datos falsos y CRUD, WebSocket, Socket.IO y gRPC, la terminal, Docker y agentes de IA.

Descargar Mockix