Probar guards, rutas y stores sin miedo

Auth y rutas protegidas

El guard no es la única seguridad del sistema, pero sí protege la experiencia del frontend. Su trabajo es simple: si hay sesión válida, deja pasar; si no, redirige al login.

Un buen test de guard debe cubrir tres situaciones: usuario anónimo, usuario autenticado y usuario que vuelve desde una URL protegida.

El guard no reemplaza la seguridad del backend

Por eso estos specs no deberían venderse como “seguridad completa”. Sirven para evitar regresiones visibles: perder el `returnUrl`, mostrar una ruta privada sin sesión o dejar activo un tenant incorrecto después de un error.

Ejemplo: mantener returnUrl

it('redirige al login con la URL original', () => {
  authStore.setAnonymous();

  const result = runGuardFor('/products');

  expect(result).toEqual(
    router.parseUrl('/login?returnUrl=%2Fproducts'),
  );
});

Stores con signals

Un store con signals expone estado que Angular puede leer de forma reactiva. En un test, lo importante es verificar qué valor queda después de una acción.

it('vuelve al tenant anterior si el cambio falla', async () => {
  tenantStore.setActive(currentTenant);
  api.switchTenant.mockRejectedValue(new Error('Forbidden'));

  await expect(tenantStore.switchTo(nextTenant)).rejects.toThrow();

  expect(tenantStore.activeTenant()).toEqual(currentTenant);
});

Matriz mínima de casos

Antes de pedirle a Codex que implemente, conviene pedirle una matriz corta. Así la conversación se ordena por riesgo y no por archivos sueltos.

- Usuario anónimo entra a ruta privada -> login con returnUrl.
- Usuario autenticado entra a ruta privada -> acceso permitido.
- Login exitoso con returnUrl -> vuelve a la ruta original.
- Cambio de tenant exitoso -> actualiza contexto y permisos.
- Cambio de tenant fallido -> vuelve al tenant anterior.
- Tenant sin módulos -> muestra estado controlado, no rompe navegación.

Cómo usamos Codex en auth y tenants

Auth y tenants son buenos ejemplos porque conectan código técnico con riesgos fáciles de entender: una persona no debería entrar sin sesión, perder el `returnUrl` al iniciar sesión ni operar sobre la empresa equivocada.

1. Mostrar los archivos que protegen el flujo

   Parte por `src/app/core/auth/auth.guard.ts`, `auth.guard.spec.ts`, `auth-redirect.service.ts`, `src/app/core/tenant/tenant.store.ts` y `tenant.store.spec.ts`.

2. Pedir casos antes de implementar

   Pídele a Codex una matriz corta de casos: usuario anónimo, usuario autenticado, `returnUrl`, tenant activo, tenant sin módulos o error al refrescar contexto.

3. Implementar un solo caso visible

   Para mantener el cambio acotado, implementa solo un spec. Por ejemplo: usuario anónimo intenta entrar a una ruta privada y el guard redirige al login conservando `returnUrl`.

4. Validar que no se rompió nada más

   Muestra el diff de `auth.guard.spec.ts` o `tenant.store.spec.ts`, revisa los scripts disponibles con `npm pkg get scripts`, ejecuta `npm run typecheck` y luego `npm run test:ci` si existen en el repo. Si el cambio toca navegación visible, suma una revisión en navegador.

Revisa src/app/core/auth/auth.guard.ts, auth.guard.spec.ts, auth-redirect.service.ts,
src/app/core/tenant/tenant.store.ts y tenant.store.spec.ts.
Propón 3 casos críticos relacionados con sesión, returnUrl y tenant activo.
Implementa solo el test más pequeño y explícame qué riesgo cubre.
Muestra los archivos modificados y los comandos exactos para verificar.

npm pkg get scripts
git diff -- src/app/core/auth/auth.guard.spec.ts src/app/core/tenant/tenant.store.spec.ts
npm run typecheck
npm run test:ci

Qué se gana con estos tests

Estos tests reducen regresiones invisibles. La pantalla puede verse igual, pero un guard o un store roto puede cambiar completamente el comportamiento real.

Recursos relacionados