Mockingbird: la extensión de Chrome que he creado para mockear APIs desde el navegador
Ya está publicada en la Chrome Web Store
Durante las últimas semanas he estado trabajando en Mockingbird, una extensión de Chrome para desarrolladores frontend que permite mockear respuestas de APIs directamente desde el navegador.
La idea nació de una molestia bastante común: estás construyendo una pantalla, necesitas probar qué pasa cuando el backend devuelve un 500, una sesión expira, una petición tarda demasiado o la red falla, y acabas cambiando código temporalmente, levantando un mock server o pidiendo a backend que fuerce un caso concreto.
Mockingbird evita todo eso. Intercepta las llamadas que hace tu aplicación y responde por sí misma, sin proxy, sin backend adicional y sin cambiar una sola línea de tu código.

Puedes instalarla desde la página oficial de Mockingbird en Chrome Web Store.
Por qué quería crearla
Hay muchas herramientas para mockear APIs, pero casi siempre me encontraba con el mismo problema: modificaban el cuerpo de la respuesta, pero dejaban el estado HTTP en 200.
Eso parece suficiente hasta que quieres probar el manejo real de errores. Si tu frontend recibe un 200, response.ok sigue siendo true, Axios no entra en el catch, Angular no emite un HttpErrorResponse y tu UI de error nunca se ejecuta como lo haría en producción.
Lo que yo quería era más simple y más honesto: si configuro un 500, quiero que sea un 500 de verdad.
Por eso Mockingbird devuelve códigos HTTP reales:
fetchresuelve conresponse.ok === falseyresponse.status === 500.XMLHttpRequesttermina conxhr.status === 500.axiosrechaza conerror.response.status === 500.- Angular
HttpClientemite unHttpErrorResponsecon el estado correcto.
Ese detalle cambia mucho la forma de probar una interfaz, porque por fin el código de error se ejecuta tal como se ejecutaría contra una API real.
También simula fallos de red
Un error HTTP no es lo mismo que un fallo de red.
Un 500 significa que la petición llegó al servidor y el servidor respondió con un error. Un fallo de red significa que la petición no llegó, que el usuario está offline o que el navegador no pudo completar la conexión.
Mockingbird permite simular ambos casos. Cuando configuras un fallo de red, fetch rechaza con un TypeError, XHR dispara error con estado 0 y Axios cae en el catch sin error.response.
Esto es importante para probar pantallas offline, reintentos, mensajes de conexión perdida y estados que muchas veces se quedan sin testear hasta que aparecen en producción.
Escenarios, delays y reglas reutilizables
La extensión funciona con reglas. Cada regla define qué URL debe interceptar, qué respuesta debe devolver, qué código HTTP usar y si debe aplicar algún delay.
Después esas reglas se pueden agrupar en escenarios. Por ejemplo:
Backend down: varias APIs responden con500.Expired login: los endpoints protegidos devuelven401.Slow connection: las respuestas llegan con varios segundos de retraso.Happy path: todo responde correctamente, pero sin depender del backend real.
Puedes activar varios escenarios a la vez. Las reglas se suman y la primera coincidencia gana, así que es fácil construir combinaciones para probar una pantalla en condiciones más cercanas a la realidad.
También incluye patrones glob o expresiones regulares, un tester para validar si una URL coincide, un editor en el side panel de Chrome, un log de las respuestas interceptadas e importación/exportación en JSON para compartir la configuración con el equipo.
Todo se ejecuta localmente en el navegador. Mockingbird no envía tus datos a ningún servidor.
El logo
Quería que el icono fuese simple, reconocible y que tuviese relación con el nombre. El mockingbird, o sinsonte, es un pájaro conocido por imitar sonidos. La metáfora encajaba bastante bien: la extensión imita respuestas de una API para que puedas construir y probar tu frontend sin depender de que todo lo demás esté listo.
![]()
El resultado es un icono morado, muy directo, pensado para funcionar bien tanto en la barra de extensiones como en la Chrome Web Store.
Dejé pasar agosto para ver si alguien la usaba
Publicar una herramienta pequeña siempre deja una duda: ¿la va a usar alguien aparte de mí?
Por eso decidí dejar pasar agosto antes de escribir este post. No quería anunciarla el mismo día de publicarla y quedarme solo con la emoción del lanzamiento. Prefería esperar un mes, mirar los datos y comprobar si había señales reales de uso.
La respuesta ha sido positiva: durante los últimos 30 días Mockingbird ha tenido 42 instalaciones.

No es una cifra enorme, pero para una extensión nueva, sin campaña, construida como herramienta para desarrolladores y publicada desde cero, me parece una señal muy buena. Lo suficiente como para seguir puliéndola y compartirla con más gente.
Si construyes frontend, pruébala
Mockingbird está pensada para esos momentos en los que necesitas comprobar cómo se comporta tu producto cuando el backend no responde como esperas.
Si trabajas con formularios, dashboards, flujos de login, pagos, pantallas offline, estados de carga o cualquier interfaz que dependa de una API, te puede ahorrar bastante tiempo.
Puedes descargarla aquí:
Instalar Mockingbird desde Chrome Web Store
Si la pruebas y encuentras algo que mejorar, me encantará leer feedback. La extensión ya está publicada, pero la parte interesante empieza ahora: convertirla en una herramienta cada vez más útil para quienes construimos frontend todos los días.