E2E, Playwright y validación de flujos reales

Qué valida un E2E

Un E2E responde una pregunta más amplia que “¿se ve bien?”: ¿el flujo funciona de punta a punta como lo usará una persona? Ahí entran clicks reales, formularios, navegación, llamadas HTTP, respuestas del backend, cambios de estado y mensajes en pantalla.

En proyectos como el backoffice y la tienda pública, Playwright permite verificar que login, tenants, catálogo, carrito o checkout llamen a los servicios correctos y terminen en un estado coherente. En el help center también sirve para rutas públicas, búsqueda, links, SSR/prerender y responsive.

La cadena E2E

1. Preparar el estado inicial

   Antes de abrir la pantalla, define qué datos necesita el flujo: usuario autenticado, tenant activo, producto disponible, carrito vacío o una orden de prueba.

2. Ejecutar acciones reales

   El test hace lo que haría una persona: entra a una ruta, llena un formulario, presiona un botón, cambia de tenant, agrega un producto o avanza un checkout.

3. Validar servicios y respuestas

   Playwright puede esperar respuestas de red, revisar status HTTP y confirmar que una acción disparó el endpoint esperado. Esto conecta la UI con servicios reales o mocks controlados.

4. Comprobar el estado final

   El flujo no termina cuando el botón responde. Termina cuando la UI muestra el resultado correcto: sesión iniciada, listado actualizado, compra creada, error controlado o tenant cambiado.

5. Revisar UI, consola y producción

   Después se miran errores de consola, responsive, textos cortados, assets, rutas profundas y, cuando aplica, SSR o producción. Lo visual sigue importando, pero como parte del flujo.

E2E automatizado o revisión asistida

No toda revisión en navegador tiene que transformarse en un test E2E permanente. El criterio es frecuencia y riesgo: si el flujo debe protegerse en cada release, se automatiza; si el cambio es puntual, puede bastar con abrir la ruta, recorrer el flujo y guardar evidencia.

1. Revisión visual asistida

   Úsala para copy, layout, contenido editorial, responsive, páginas públicas o comparación contra diseño. Aquí el foco principal es mirar y documentar.

2. Test E2E

   Úsalo para login, checkout, creación de entidades, permisos, returnUrl, tenants o flujos que dependen de servicios y deben pasar siempre antes de publicar.

3. Validación de red o API

   Úsala cuando necesitas comprobar que el frontend llama al endpoint correcto, que la respuesta llega con status esperado o que el estado del servidor quedó actualizado.

4. Snapshot visual

   Úsalo cuando una pantalla es estable y queremos detectar cambios visuales no intencionales. Si el contenido cambia mucho, conviene usar capturas manuales o asserts más específicos.

Prompts concretos para usar Codex

Busca primero qué flujos ya están cubiertos antes de proponer tests nuevos.

Revisa e2e/, playwright.config.ts, tests/integration/ y specs relacionadas.
Separa E2E de navegador, integración API y tests unitarios.
Lista rutas, servicios, datos creados, permisos modificados y comandos para demostrarlo.

Usando la cobertura existente como referencia, propón un nuevo flujo E2E para este caso:
[describe aquí el flujo: login, cambio de rol, checkout, tenant o búsqueda]

Antes de editar, dime:
1. qué datos necesita crear el test,
2. qué servicios debe validar,
3. qué estado final debe quedar visible,
4. qué riesgo evita automatizarlo.

Abre la ruta real en navegador y ejecuta el flujo como usuario.

Valida respuesta de red, estado final visible, errores de consola y responsive.
Si encuentras un problema, dime el archivo probable antes de editar.
Si el flujo es crítico y repetible, propón convertirlo en Playwright.

Casos reales encontrados en Neges

Al revisar los proyectos, aparecen dos niveles que se complementan. `neges-backffice` tiene E2E de navegador con Playwright: abre la app, completa formularios y comprueba pantallas reales. `neges-strapi` tiene integración API: crea usuarios, cambia roles, modifica permisos y valida que el backend permita o bloquee acciones según corresponda.

1. Backoffice: E2E de navegador real

   En `neges-backffice/e2e/public-auth.spec.ts`, el test crea una cuenta y tenant de prueba, espera correos en Mailpit, abre `/login`, valida el reenvío de activación, prueba un token inválido y confirma que resetear la contraseña invalida la sesión antigua.

2. Strapi: permisos y roles por API

   En `neges-strapi/tests/integration/live-api.test.cjs`, los tests crean usuarios tenant, asignan roles como `viewer` o `manager`, crean roles personalizados, expanden permisos y validan `effectiveFeatures` y respuestas 403 cuando el usuario no tiene autorización.

3. Storefront: checkout cubierto por specs

   En `neges-store`, hoy existen specs de carrito, checkout, órdenes, catálogo y SEO. No son E2E de navegador todavía, pero son una buena base para que Codex proponga un flujo Playwright futuro: catálogo, producto, carrito, checkout y confirmación.

const email = uniqueEmail('pw-login-resend');

await registerTenant({
  fullName: 'Playwright Resend User',
  email,
  password,
  companyName: `Playwright Company ${Date.now()}`,
});

await page.goto('/login');
await page.getByLabel('Correo Electronico').fill(email);
await page.getByLabel('Contrasena').fill(password);
await page.getByRole('button', { name: 'Iniciar sesion' }).click();

await expect(
  page.getByText('Tu cuenta todavia no esta activada.')
).toBeVisible();

const createdUser = await request({
  path: '/api/tenant/users',
  method: 'POST',
  accessToken: adminSession.accessToken,
  tenantDocumentId: primaryTenantDocumentId,
  body: {
    data: {
      username,
      email,
      password: integrationConfig.auth.tempUserPassword,
      role: { key: 'viewer' },
      state: 'invited',
    },
  },
});

assert.equal(createdUser.status, 201);
assert.equal(createdUser.body?.data?.role?.key, 'viewer');

const updatedRole = await request({
  path: `/api/admin/roles/${customRoleDocumentId}`,
  method: 'PUT',
  accessToken: adminSession.accessToken,
  body: {
    data: {
      key: customRoleKey,
      name: `${customRoleName} Updated`,
      permissions: expandedPermissions,
    },
  },
});

assert.equal(updatedRole.status, 200);
assert.deepEqual(sortStrings(
  customRoleWhoamiAfterUpdate.body?.effectiveFeatures ?? []
), ['products.read', 'users.read']);

Cómo lo aterrizamos en proyectos Neges

1. Help center

   Usa `neges-help-center` para revisar contenido público: blog, búsqueda y artículos. Lo importante es confirmar SSR/prerender, SEO básico, links internos y responsive.

2. Backoffice

   Usa `neges-backffice` para demostrar un E2E real de navegador. Primero se levanta el backend y Mailpit; luego Playwright abre login, usa datos creados por helper API y comprueba que el flujo termina en la pantalla correcta.

3. Backend Strapi

   Usa `neges-strapi` para enseñar la parte que el navegador no muestra: creación de usuarios, sesiones, roles, permisos, módulos tenant y errores 403 cuando una acción no está permitida.

4. Tienda pública

   Usa `neges-store` para explicar el siguiente paso natural: convertir la cobertura actual de carrito, checkout, órdenes, catálogo y SEO en un E2E de navegador para el flujo de compra.

5. Umas

   Usa `umas` para páginas institucionales y contenido visual. Las capturas en `output/playwright/` sirven como evidencia de cambios responsive o secciones complejas.

# 1. Backend requerido por el E2E del backoffice
cd ../neges-strapi
npm run develop

# 2. Mailpit captura los correos de activación y reset password
docker run --rm -p 1025:1025 -p 8025:8025 axllent/mailpit

# 3. Backoffice: Playwright levanta la app y ejecuta el flujo
cd ../neges-backffice
npm run start:e2e
npm run e2e

# 4. Para mostrarlo con navegador visible
npm run e2e:headed

# Buscar rápido la evidencia desde Codex
rg -n "registerTenant|Mailpit|reset-password" neges-backffice/e2e
rg -n "tenant/users|custom roles|effectiveFeatures|FEATURE_NOT_ALLOWED" neges-strapi/tests/integration/live-api.test.cjs
rg -n "finalizes checkout|storefront|orders" neges-store/src/**/*.spec.ts

Cuándo usar E2E y cuándo basta una revisión visual

Si el flujo es crítico, depende de servicios y se repite, conviene automatizarlo como E2E. Si el cambio es visual, puntual o editorial, puede bastar con abrir navegador, recorrer la pantalla, revisar responsive y dejar capturas.

Recursos relacionados