Si escribes pruebas de frontend, probablemente te has encontrado con Mock Service Worker (MSW). Es la biblioteca de referencia para interceptar solicitudes dentro del navegador y Node, y para pruebas unitarias y de componentes es difícil de superar. Esta guía explica qué hace bien MSW, dónde deja de escalar y cuándo una plataforma alojada de simulación de API tiene más sentido.
¿Qué es Mock Service Worker?
Mock Service Worker es una biblioteca de JavaScript que intercepta solicitudes de red en la fuente. En el navegador, registra un Service Worker que intercepta las llamadas salientes a fetch y XMLHttpRequest. En Node, parchea la capa de solicitud para que los mismos manejadores se ejecuten en Jest o Vitest. Se escriben manejadores de solicitudes que coinciden con un método y una ruta, y luego se devuelve la respuesta deseada.
El diseño es ingenioso. El código de tu aplicación sigue llamando a las API de red reales. MSW se interpone y responde, por lo que no necesitas simular fetch ni cambiar tu cliente HTTP. Las mismas definiciones de simulacro funcionan en pruebas y en una compilación de desarrollo en ejecución, por eso tantos equipos de React y Vue lo utilizan. Puedes consultar el código fuente de MSW en GitHub para ver cómo funciona la capa de intercepción.
Un manejador típico se ve así:
import { http, HttpResponse } from 'msw'
export const handlers = [
http.get('/api/users/:id', ({ params }) => {
return HttpResponse.json({ id: params.id, name: 'Ada Lovelace' })
}),
]
Esa es toda su atracción. El simulacro vive junto a tu código, está controlado por versiones con tus pruebas y se ejecuta dondequiera que se ejecute tu JavaScript.
Dónde destaca MSW
MSW es una excelente opción cuando el simulacro y el consumidor viven en la misma base de código. Algunos casos en los que es realmente la herramienta adecuada:
- Pruebas de componentes y unitarias. Renderiza un componente, deja que dispare sus solicitudes reales y devuelve datos predefinidos. No hay dobles de prueba que configurar. Si lo comparas con espiar al cliente directamente, mira cómo esto difiere de una simulación de Jest de una llamada a la API.
- Desarrollo local de frontend. Construye la interfaz de usuario antes de que exista el backend. Alterna los manejadores para simular la carga, errores o estados vacíos bajo demanda.
- CI determinista. Las pruebas no tocan un servidor en vivo, por lo que no fallan por condiciones de red o datos de staging compartidos.
- Un idioma, un equipo. Cuando las personas que escriben el simulacro son las mismas que lo consumen, mantener los manejadores en el repositorio es el camino más simple.
Si esa describe tu situación, probablemente no necesites nada más. MSW es gratuito, de código abierto y fue creado exactamente para esto.
Dónde MSW comienza a flaquear
Lo mismo que hace que MSW sea excelente en un solo repositorio, los simulacros que viven como código en ese repositorio, es lo que lo limita una vez que más personas se involucran. Aquí es donde los equipos tienden a superarlo.
Consumidores que no son JavaScript
Los manejadores de MSW son JavaScript. Si tu equipo móvil escribe Swift o Kotlin, o tus pruebas de integración de backend se ejecutan en Go o Python, no pueden importar tus manejadores. Necesitarían sus propios simulacros, que se desviarían de los tuyos. Un servidor de simulación agnóstico al lenguaje que habla HTTP a través de una URL real funciona para cualquier cliente, sin importar el lenguaje.
Simulacros compartidos y siempre activos
MSW se ejecuta dentro de un proceso. No hay una URL compartida a la que un ingeniero de control de calidad, un diseñador o un equipo asociado pueda acceder desde su propia máquina. En el momento en que quieras un punto final que varias personas usen a la vez, necesitas un servidor de simulación alojado con una dirección estable, no un Service Worker vinculado a una pestaña del navegador.
Flujos de trabajo basados en el diseño y en esquemas
Si diseñas APIs en OpenAPI antes de escribir código, querrás simulacros generados automáticamente a partir de la especificación, para que el simulacro no discrepe con el contrato. MSW espera que escribas los manejadores a mano. Generar simulacros directamente desde un esquema es un modelo diferente. Puedes leer más sobre este enfoque en esta guía sobre la simulación de API y los patrones que la rodean.
Datos realistas y dinámicos a escala
MSW devuelve lo que tu manejador codifica. Para datos realistas en muchos campos, escribes esa lógica tú mismo. Las plataformas que incorporan generación estilo faker e inferencia de nombres de campo te brindan respuestas realistas sin tener que crear cada una a mano.
MSW vs. una plataforma completa de simulación de API
Aquí hay una comparación honesta. Ninguna columna es "mejor" en abstracto; resuelven problemas diferentes.
| Capacidad | Mock Service Worker | Plataforma de API alojada (ej. Apidog) |
|---|---|---|
| Se ejecuta dentro de pruebas unitarias/de componentes de JS | Sí, nativo | No, no es una biblioteca de pruebas de JS |
| Agnóstico al lenguaje sobre HTTP | No (solo JS) | Sí, cualquier cliente |
| URL compartida para todo el equipo | No | Sí, servidor de simulación alojado |
| Genera simulacros desde OpenAPI | Manual | Automático desde el esquema |
| Generación de datos inteligente/dinámica | Codificado a mano | Integrado |
| Vive en tu repositorio con pruebas | Sí | Almacenado en proyecto compartido |
| Costo | Gratuito, código abierto | Nivel gratuito + planes de pago |
La conclusión: MSW es la opción correcta para pruebas de frontend y desarrollo local. Una plataforma como Apidog es la opción correcta cuando el simulacro debe ser compartido, agnóstico al lenguaje o impulsado por una especificación.
Apidog como complemento, no como reemplazo
Para ser claros, Apidog no es un reemplazo directo para MSW dentro de Jest o Vitest. No es una biblioteca de JavaScript que importas en un archivo de prueba. Trátalo como la capa superior a tus pruebas unitarias, el lugar donde los simulacros se convierten en un recurso compartido y agnóstico al lenguaje para todo el equipo.
Así es como se ve en la práctica. Diseñas o importas una API en Apidog, y genera un endpoint simulado automáticamente a partir del esquema. El simulacro obtiene una URL real a la que tu equipo de frontend, móvil y QA pueden llamar. Apidog rellena las respuestas con datos realistas infiriendo de los nombres de los campos, por lo que un campo llamado email devuelve un correo electrónico y createdAt devuelve una fecha. También puedes escribir reglas personalizadas cuando necesites una respuesta específica de 500 o un caso extremo particular.
Como el simulacro proviene del mismo esquema que tu diseño y pruebas, se mantiene sincronizado con el contrato. Esa es la parte que los manejadores escritos a mano no pueden garantizar. Si quieres ver cómo se compara la generación de esquema a simulacro entre herramientas, este resumen de las mejores herramientas de simulación de API pone las opciones una al lado de la otra.
Una división práctica que muchos equipos adoptan:
- Mantener MSW para pruebas de componentes y unitarias dentro del repositorio de frontend.
- Utilizar un simulacro alojado para integración entre equipos, demostraciones y cualquier consumidor que no sea JS.
No estás eligiendo uno. Estás usando cada uno donde encaja. Descarga Apidog si quieres probar el lado alojado junto con tu configuración MSW existente.
Otras alternativas de MSW que vale la pena conocer
MSW no es la única biblioteca de simulación, y una plataforma no es tu única opción. Dependiendo de tu stack:
- Mockoon es una aplicación de escritorio para crear servidores de simulación locales rápidamente, con una interfaz gráfica de usuario en lugar de código.
- WireMock es un servidor de simulación basado en Java, ideal para equipos JVM y pruebas de contrato.
- Prism de Stoplight genera un simulacro directamente desde un archivo OpenAPI a través de la línea de comandos.
- json-server convierte un archivo JSON en una API REST rápida para prototipos.
Cada uno tiene sus ventajas y desventajas. WireMock y Prism se inclinan hacia el trabajo de backend y contratos; Mockoon y json-server se inclinan hacia una configuración local rápida. Si tu obstáculo es específicamente "MSW no puede ayudar a mis compañeros de equipo que no usan JS", cualquier servidor de simulación basado en HTTP lo resuelve. Para un ángulo de frontend más amplio, mira cómo los equipos manejan la simulación de API en React con Axios.
Preguntas frecuentes
¿Es MSW gratuito?
Sí. Mock Service Worker es de código abierto bajo la licencia MIT y de uso gratuito en cualquier proyecto, comercial o no. Solo empiezas a pagar cuando te pasas a una plataforma alojada para simulacros compartidos, y herramientas como Apidog también incluyen un nivel gratuito para eso.
¿Puede Apidog reemplazar a MSW en mis pruebas unitarias?
No, y no deberías intentarlo. MSW intercepta las solicitudes dentro de tu ejecutor de pruebas de JavaScript. Apidog es una plataforma alojada, no una biblioteca importable, por lo que no puede funcionar dentro de Jest o Vitest como lo hace MSW. Usa Apidog para simulacros compartidos, entre equipos o basados en esquemas. Si te enfocas puramente en el lado del ejecutor de pruebas, este tutorial sobre cómo simular llamadas a la API cubre los enfoques dentro del código.
¿MSW funciona en Node, o solo en el navegador?
En ambos. En el navegador, MSW utiliza un Service Worker. En Node, parchea la capa de solicitud para que los mismos manejadores se ejecuten en Jest, Vitest o cualquier entorno de prueba de Node. Ese modo dual es una de sus mayores fortalezas para los equipos de JS full-stack.
¿Cuándo debería cambiar de MSW a un servidor de simulación alojado?
Cambia, o más bien añade uno, cuando el simulacro necesite ser compartido. Las señales más claras: un cliente que no es JavaScript lo necesita, varias personas necesitan la misma URL estable, o diseñas APIs priorizando la especificación y quieres que los simulacros se generen automáticamente desde OpenAPI.
Conclusión
MSW es excelente en lo que fue creado para hacer: interceptar solicitudes dentro de JavaScript para pruebas de frontend y unitarias. No intenta ser un simulacro compartido, alojado y agnóstico al lenguaje, y eso está bien. Cuando tus simulacros necesitan salir del repositorio, cuando otros lenguajes u otros equipos los necesitan, o cuando quieres que se generen a partir de una especificación, ese es el momento de añadir una plataforma completa junto a él.
Apidog maneja el lado compartido y basado en esquemas: un servidor de simulación alojado con una URL real, simulacros automáticos desde tu diseño OpenAPI y datos realistas listos para usar. Mantén MSW donde es fuerte y deja que Apidog cubra todo lo que va más allá del límite de tu ejecutor de pruebas. Descarga Apidog y apunta tu frontend a un simulacro compartido para ver la diferencia.