Las APIs de producción pueden fallar en cualquier momento, y cuando eso pasa tus tests caen como fichas de dominó. Mock Service Worker (MSW) resuelve ese problema interceptando peticiones HTTP a nivel de red para que simules respuestas controladas en tu ambiente de pruebas, sin tocar el código de producción.

¿Qué es Mock Service Worker y cómo funciona?

MSW es una biblioteca de interceptación de red que configura un Service Worker (un script que el navegador ejecuta en segundo plano, parecido a un proxy) para escuchar tus peticiones HTTP y devolver respuestas simuladas [00:09].

¿Qué es un Service Worker? Un script que tu navegador corre en segundo plano y actúa como proxy entre tu app y la red. MSW lo usa para interceptar requests sin que tu código de producción se entere.

Algunas características que lo hacen interesante:

• Funciona tanto en testing como en desarrollo.
• Intercepta requests a nivel de red, no a nivel de código.
• Mantiene tu código de producción intacto.
• Es compatible con REST, GraphQL y otros protocolos.

¿Cómo instalo MSW en mi proyecto?

La instalación arranca con un solo comando en la terminal de Visual Studio Code [01:25]:

bash yarn add -D msw

Ojo: aunque la librería se llame Mock Service Worker, el paquete en npm es solo msw. La bandera -D lo guarda como dependencia de desarrollo, que es justo lo que quieres para una herramienta de testing.

¿Dónde organizo los archivos de MSW?

La propia documentación recomienda crear una carpeta mocks dentro de src para encapsular toda la configuración [01:55]. Puedes usar otro nombre, pero seguir la convención te ayuda a leer ejemplos de la comunidad sin fricción.

Cómo defino los handlers de mis endpoints

Dentro de mocks creas un archivo handlers.ts. Aquí declaras qué endpoints va a interceptar MSW y qué deben devolver [02:15]:

ts import { http, HttpResponse } from 'msw'

export const handlers = [ http.get('http://localhost:3001/orders', () => { return HttpResponse.json([ // arreglo de órdenes simulado desde db.json ]) }), ]

La URL que pasas a http.get debe coincidir con la que tu app realmente consume. Si tu empresa usa platzi.com/api, ese mismo dominio va aquí. En el ejemplo se usa localhost:3001/orders porque el proyecto consume una API local levantada con yarn start [02:50].

Dentro del callback retornas HttpResponse.json con los datos que esperas. En la clase se reutiliza el primer registro del db.json que ha acompañado al curso, así el test recibe datos consistentes.

Cómo configuro el servidor de pruebas

MSW necesita un servidor que escuche durante los tests. Creas server.ts dentro de mocks [04:10]:

ts import { setupServer } from 'msw/node' import { handlers } from './handlers'

export const server = setupServer(...handlers)

Fíjate en msw/node: ese subpath es el que expone setupServer, la función que arma el servidor en entorno Node. Le pasas los handlers con spread para que sepa qué rutas debe responder.

¿Cómo conecto MSW con mi setup de tests?

Falta avisarle a tu configuración de tests que use ese servidor. En el archivo setup-test que creaste al inicio del curso agregas los hooks de Vitest [05:15]:

ts import { afterAll, afterEach, beforeAll } from 'vitest' import { server } from './mocks/server'

beforeAll(() => server.listen()) afterEach(() => server.resetHandlers()) afterAll(() => server.close())

Cada hook tiene un rol específico:

• beforeAll arranca el servidor una sola vez antes de todos los tests.
• afterEach resetea los handlers tras cada test para evitar contaminación entre casos.
• afterAll cierra el servidor cuando termina la suite completa.

¿Por qué usar resetHandlers después de cada test? Para que un test no herede mocks modificados de otro. Cada caso queda aislado y reproducible.

¿MSW modifica mi código de producción? No. Intercepta a nivel de red, así que tu cliente HTTP sigue apuntando a las mismas URLs reales sin cambios.

Con beforeAll, afterEach y afterAll en su sitio, ejecutas el comando de test y deberías ver todo en verde. A partir de aquí ya tienes la base para escribir pruebas que dependan de respuestas HTTP controladas, sin sustos de inestabilidad de red.

¿Cómo estás organizando tus mocks hoy en tu proyecto? Cuéntame en los comentarios qué endpoints te gustaría simular primero.