¿Cómo mockearías red, router, Pinia y composables sin perder confianza en el comportamiento?

Respuesta

• Mockea fetch, router o servicios en el borde donde quieres aislar el caso, pero no simules toda la aplicación si no hace falta.
• Para Pinia decide cuándo usar createTestingPinia y cuándo te compensa un store real con dependencias stub para ganar confianza.
• Con composables compartidos, prioriza dobles pequeños y explícitos antes que mocks globales que cambien el comportamiento de demasiadas pruebas a la vez.

Puntos clave

• Una buena suite en Vue protege comportamiento observable: datos mostrados, errores, navegación, contratos de store y eventos emitidos.
• Los mocks deben aislar fronteras, no inventarse un sistema paralelo tan distinto que la prueba pierda valor.
• Cuando una suite es lenta o frágil, casi siempre mezcla demasiado montaje completo, estado compartido mal reseteado y assertions atadas a detalles internos.

Errores comunes

• Fijar estructura interna o snapshots demasiado frágiles hace que los tests griten por refactors sanos y callen ante bugs reales.
• Montar media aplicación en cada prueba reduce velocidad y hace más difícil aislar el comportamiento importante.

Ejemplo de código

vi.mock("vue-router", () => ({
  useRoute: () => ({ params: { id: "42" } }),
  useRouter: () => ({ push: vi.fn(), replace: vi.fn() }),
}));

vi.stubGlobal("fetch", vi.fn(() => Promise.resolve(new Response("{}"))));

Ejemplo o caso real

Es un problema muy visible cuando la suite tarda demasiado, los fallos son poco informativos o el equipo evita refactorizar por miedo a romper pruebas sin sentido.

Idea clave

Busco tests que protejan comportamiento y liberen refactor, no tests que castiguen cualquier cambio interno.