DEV Community

Cover image for ¿Bruno Tiene un Mock Server? (Y Qué Alternativas Usar)
Roobia
Roobia

Posted on • Originally published at apidog.com

¿Bruno Tiene un Mock Server? (Y Qué Alternativas Usar)

Bruno es un cliente de API ligero, nativo de Git y de código abierto. Es rápido, fácil de versionar y cómodo para trabajar con colecciones como archivos planos. Pero tiene una limitación importante para equipos que diseñan APIs en paralelo: no incluye un servidor simulado para exponer endpoints que todavía no existen. En esta guía verá cuándo aparece esa brecha, qué alternativas se suelen usar y cómo generar un servidor simulado desde una especificación OpenAPI.

Prueba Apidog hoy

Respuesta corta: Bruno no tiene un servidor simulado incorporado. Puede enviar solicitudes y ejecutar pruebas, pero no puede convertir una request guardada en un endpoint falso que devuelva respuestas de ejemplo. Para simular una API, necesita una herramienta externa o un servidor stub creado manualmente.

Por qué necesita un servidor simulado

Un servidor simulado devuelve respuestas realistas para endpoints que aún no están implementados, son inestables o son difíciles de activar bajo demanda.

Use un mock server cuando necesite:

  • Desarrollo paralelo: frontend y mobile consumen el contrato de la API mientras backend sigue implementando.
  • Pruebas de errores: puede forzar respuestas como 429, 500, 503 o payloads inválidos.
  • Demos y prototipos: muestra flujos completos sin backend, base de datos ni credenciales reales.
  • CI más estable: evita que las pruebas fallen por staging caído, límites de tasa o datos cambiantes.

Ejemplos de escenarios que puede probar de forma controlada:

Escenario Lo que devuelve el simulador Por qué es difícil de otra manera
Límite de tasa alcanzado 429 + encabezado Retry-After El backend rara vez limita bajo demanda
Caída del servidor 500 / 503 No se puede romper staging solo para probar
Respuesta lenta Cuerpo con retraso Difícil de reproducir latencia real
Conjunto de resultados vacío 200 con [] Depende de un estado de datos específico
Payload mal formado Cuerpo sin un campo requerido La validación del backend normalmente lo impide

¿Tiene Bruno un servidor simulado?

No. Bruno se enfoca en:

  • Enviar solicitudes HTTP.
  • Organizar colecciones como archivos planos.
  • Ejecutar aserciones y pruebas.
  • Mantener un flujo de trabajo compatible con Git.

Pero no incluye una función nativa para levantar un mock server ni una opción para convertir una request guardada en un stub accesible por URL.

En la práctica, los usuarios de Bruno suelen resolverlo de dos maneras.

Opción 1: usar una herramienta externa de mocking

Puede ejecutar una herramienta como:

  • Mockoon
  • WireMock
  • Prism
  • json-server

El flujo típico es:

  1. Define los endpoints y respuestas en la herramienta externa.
  2. Levanta el mock server local o remoto.
  3. Configura Bruno para enviar requests contra esa URL.

Ejemplo conceptual:

# Mock server externo
http://localhost:3001/users

# Bruno apunta a esa URL
GET http://localhost:3001/users
Enter fullscreen mode Exit fullscreen mode

Funciona, pero ahora mantiene dos espacios separados: las requests en Bruno y las respuestas mock en otra herramienta.

Opción 2: crear un servidor stub manual

También puede crear un servidor pequeño con Express, Flask o FastAPI.

Ejemplo básico con Express:

import express from "express";

const app = express();

app.get("/users", (req, res) => {
  res.json([
    {
      id: 1,
      name: "Ana García",
      email: "ana@example.com"
    }
  ]);
});

app.get("/users/:id", (req, res) => {
  res.json({
    id: Number(req.params.id),
    name: "Usuario de prueba",
    email: "user@example.com"
  });
});

app.listen(3001, () => {
  console.log("Mock server running on http://localhost:3001");
});
Enter fullscreen mode Exit fullscreen mode

Después apunta Bruno a:

GET http://localhost:3001/users
Enter fullscreen mode Exit fullscreen mode

Este enfoque es rápido para uno o dos endpoints, pero se vuelve tedioso cuando la API crece.

El costo de la simulación “bolt-on”

Añadir una capa de simulación separada a Bruno es viable, pero introduce fricción operativa.

Los problemas más comunes son:

  • Desfase entre fuentes de verdad: la especificación, las requests de Bruno y las respuestas mock viven en lugares distintos.
  • Configuración adicional: cada nuevo miembro del equipo debe instalar y configurar otra herramienta.
  • Respuestas escritas a mano: hay que mantener ejemplos para cada endpoint, campo y código de estado.
  • Datos poco realistas: muchos stubs devuelven siempre el mismo "nombre": "cadena", lo que oculta errores que aparecen con datos variados.

Nada de esto bloquea el trabajo, pero sí aumenta el mantenimiento. Para una comparación más amplia, consulte este análisis de la plataforma API todo en uno alternativa a Bruno.

Genere un servidor simulado desde su especificación OpenAPI

Una alternativa más mantenible es generar el mock server desde el contrato que ya usa para diseñar la API.

Apidog permite importar o escribir una especificación OpenAPI y generar un servidor simulado a partir de esas definiciones. Así, el diseño, las pruebas, la documentación y la simulación parten de la misma fuente.

La diferencia práctica es que no tiene que mantener un mock separado endpoint por endpoint.

Apidog puede:

  • Generar respuestas desde el esquema OpenAPI.
  • Devolver datos plausibles según nombres y tipos de campos.
  • Exponer una URL simulada sin escribir ni alojar un servidor propio.
  • Mantener el simulador sincronizado con la especificación.
  • Permitir ajustes para casos concretos, como respuestas 429, 500 o payloads específicos.

Por ejemplo, si su esquema define un usuario así:

User:
  type: object
  properties:
    id:
      type: integer
      example: 123
    name:
      type: string
      example: Ana García
    email:
      type: string
      format: email
    created_at:
      type: string
      format: date-time
Enter fullscreen mode Exit fullscreen mode

El simulador puede devolver una respuesta con la misma forma:

{
  "id": 123,
  "name": "Ana García",
  "email": "ana@example.com",
  "created_at": "2026-06-02T10:30:00Z"
}
Enter fullscreen mode Exit fullscreen mode

Como el mock, las requests y la documentación salen del mismo proyecto, se reduce el riesgo de que una definición quede obsoleta. Si su equipo trabaja con Git, también puede mantener la especificación versionada y revisable dentro de un flujo de trabajo de API nativo de Git.

Para más escenarios prácticos, consulte estos casos de uso de la simulación de API.

Guía rápida: de OpenAPI a una URL simulada

Este es el flujo básico para levantar un servidor simulado desde una especificación existente.

1. Importe la especificación

Importe su archivo OpenAPI o Swagger en Apidog, o apunte a la URL donde está publicada la especificación.

Ejemplos de entrada:

openapi.yaml
openapi.json
https://example.com/openapi.json
Enter fullscreen mode Exit fullscreen mode

Los endpoints, métodos, parámetros y esquemas se importan desde el contrato.

2. Abra un endpoint importado

Seleccione un endpoint, por ejemplo:

GET /users/{id}
Enter fullscreen mode Exit fullscreen mode

Como el endpoint ya tiene parámetros, esquema de respuesta y ejemplos definidos en OpenAPI, el simulador tiene la información necesaria para generar una respuesta.

3. Copie la URL simulada

Apidog expone una URL mock para consumir el endpoint sin desplegar backend propio.

Puede usarla en:

  • Aplicaciones frontend.
  • Apps móviles.
  • Pruebas automatizadas.
  • Demos internas.
  • Pipelines de CI.

4. Envíe una request contra el mock

Ejemplo con curl:

curl https://mock.example.com/users/123
Enter fullscreen mode Exit fullscreen mode

Respuesta esperada:

{
  "id": 123,
  "name": "Ana García",
  "email": "ana@example.com",
  "created_at": "2026-06-02T10:30:00Z"
}
Enter fullscreen mode Exit fullscreen mode

5. Ajuste respuestas para casos específicos

Si necesita probar una ruta de error, configure una respuesta concreta.

Por ejemplo:

HTTP/1.1 429 Too Many Requests
Retry-After: 60
Enter fullscreen mode Exit fullscreen mode

Con cuerpo:

{
  "error": "rate_limit_exceeded",
  "message": "Inténtelo de nuevo más tarde."
}
Enter fullscreen mode Exit fullscreen mode

Así puede validar cómo reacciona su cliente sin forzar el backend real a fallar.

Cuándo basta con una solución alternativa

No siempre necesita una plataforma basada en especificaciones.

Bruno más una herramienta externa puede ser suficiente si:

  • Solo necesita simular uno o dos endpoints.
  • El mock es temporal para una prueba local.
  • No necesita datos dinámicos.
  • No está probando muchas rutas de error.
  • Su equipo ya usa Mockoon, WireMock o Prism sin problemas de mantenimiento.
  • Quiere conservar Bruno como centro del flujo de trabajo.

La compensación es clara:

  • El enfoque ligero mantiene la simplicidad de Bruno.
  • El enfoque basado en especificaciones reduce el desfase entre diseño, pruebas, documentación y simulación.

Elija según el tamaño de su API y la frecuencia con la que cambian sus contratos.

Preguntas frecuentes

¿Tiene Bruno un servidor simulado incorporado?

No. Bruno es un cliente de API para enviar requests y ejecutar pruebas. No incluye un servidor simulado nativo. Para simular endpoints, debe usar una herramienta externa o escribir su propio servidor stub y apuntar Bruno hacia esa URL.

¿Cuál es la forma más fácil de añadir simulación a un flujo de trabajo estilo Bruno?

La forma más mantenible es generar el simulador desde una especificación OpenAPI. Así evita definir respuestas mock en un lugar separado y mantiene una única fuente de verdad para diseño, simulación, pruebas y documentación.

¿Puedo seguir usando Bruno y añadir un servidor simulado al lado?

Sí. Puede ejecutar Mockoon, WireMock, Prism o un servidor propio con Express, Flask o FastAPI. Funciona bien para casos pequeños, pero las requests, la especificación y los datos simulados pueden desfasarse si no se mantienen juntos.

¿Cuándo conviene pasar a mocking basado en especificaciones?

Cuando la API crece, los endpoints cambian con frecuencia o varios equipos consumen el mismo contrato. En ese punto, mantener mocks manuales suele costar más que generarlos desde OpenAPI.

Si mantener una capa de simulación separada empieza a costar más de lo que ahorra, pruebe una simulación basada en especificaciones. Importe su archivo OpenAPI en Apidog y obtendrá una URL simulada funcionando sin alojar un servidor adicional.

Top comments (0)