Configurar pruebas para los caminos felices de tu aplicación es solo la mitad del trabajo. Validar cómo responde tu código ante un error 500 es igual de importante, y con Mock Service Worker (MSW) puedes simularlo de forma clara y controlada sin depender de un backend real.
¿Cómo se configura un caso de prueba para un error 500?
A diferencia del caso exitoso, donde los handlers ya tienen definida la respuesta por defecto, para simular un error necesitas sobreescribir temporalmente la ruta dentro del propio test. Esto se logra con server.use() [0:43].
El flujo es el siguiente:
- Importas
http y HttpResponse desde msw.
- Importas el
server desde tu configuración de mocks.
- Dentro del test, llamas a
server.use() para registrar un nuevo handler que reemplaza al existente.
javascript
import { http, HttpResponse } from 'msw';
import { server } from './mocks/server';
it('debe obtener un error', async () => {
server.use(
http.get('https://tu-api.com/orders', () => {
return new HttpResponse(null, {
status: 500,
statusText: 'Internal Server Error',
});
})
);
});
La diferencia clave respecto al handler exitoso es que aquí no retornas data, solo indicas el status code 500 y el statusText correspondiente [1:15].
¿Cómo se valida el mensaje de error en el hook?
Una vez configurado el servidor para devolver el error, renderizas el hook con renderHook y esperas a que se actualice el estado con waitForNextUpdate [1:38].
javascript
const { result, waitForNextUpdate } = renderHook(() => useOrders(), {
wrapper: Wrapper,
});
await waitForNextUpdate();
const error = result.current.error;
expect(error).toBe('failed to fetch orders, please try again');
El mensaje que validas debe coincidir exactamente con el que defines en el bloque catch de tu hook useOrders. Si cambias ese texto, el test falla de inmediato, lo que demuestra que la aserción realmente está funcionando [2:10].
¿Por qué es importante probar el camino del error?
El status code 500 representa un error interno del servidor. Verificar que tu aplicación lo maneja correctamente te da confianza en que:
- El usuario recibe un mensaje claro en lugar de un fallo silencioso.
- El bloque
catch de tu lógica de fetching está funcionando.
- No hay comportamientos inesperados cuando el backend falla.
¿Qué es server.use y cuándo se necesita?
server.use() permite sobreescribir handlers en tiempo de ejecución dentro de un test específico. Los handlers originales siguen disponibles para los demás tests. Esto es fundamental cuando necesitas simular escenarios distintos al flujo principal sin modificar la configuración global de MSW [0:43].
¿Qué sigue después de cubrir ambos flujos?
Con el caso exitoso y el caso de error cubiertos, ya tienes pruebas para la parte positiva y negativa del flujo. El siguiente paso natural es ejecutar coverage sobre tu proyecto para medir qué porcentaje de tu código está respaldado por tests. Eso te permite identificar áreas sin cobertura y tomar decisiones sobre dónde enfocar el esfuerzo de testing.
Si quieres mejorar la organización de estos tests, un buen ejercicio es extraer la lógica de renderHook con su wrapper a una función reutilizable, evitando repetición entre casos de prueba. ¿Ya lo intentaste? Comparte cómo te fue.
