¿Qué estrategia de testing usarías para componentes, composables, stores y rutas?

Respuesta

• Para composables y lógica pura busca pruebas pequeñas y rápidas; para stores valida contratos de acciones, getters y asincronía importante.
• En componentes céntrate en comportamiento visible, estados de error, interacción y contratos con hijos o padre.
• Reserva pruebas de navegación o integración amplia para flujos donde realmente importa el encaje entre router, store y pantalla.

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

it("muestra el nombre del usuario actual", async () => {
  const pinia = createTestingPinia({ stubActions: false });
  const wrapper = mount(ProfileHeader, { global: { plugins: [pinia] } });

  await flushPromises();
  expect(wrapper.get("[data-testid=\"user-name\"]").text()).toContain("Manu");
});

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.