David
da362fef64
- Add E2ESchemaDatabaseConfig interface for database configuration validation. - Implement assertE2ESchemaDatabaseConfig function to enforce schema requirements. - Create prepareE2ESchema function to handle schema preparation and initialization. - Develop E2E lifecycle management functions to provision, prepare, and run tests. - Introduce Docker Compose setup for E2E database environment. - Add Playwright configuration for E2E testing. - Implement various test cases to validate E2E schema preparation and lifecycle. - Create utility functions for environment variable management and database assertions. - Establish smoke tests to verify initial data setup and integrity.
46 lines
3.0 KiB
Markdown
46 lines
3.0 KiB
Markdown
# Infraestructura browser E2E
|
|
|
|
Suite Playwright de navegador que valida frontend, backend y MariaDB reales. Es distinta de los tests HTTP/API integration de `apps/server/src/testing/http`, cuyo runtime y lifecycle son independientes.
|
|
|
|
## Estructura
|
|
|
|
El primer nivel debe coincidir exactamente con el módulo propietario en `modules`: por ejemplo, `identity` usará `tests/e2e/identity/login.spec.ts` y facturas de clientes `tests/e2e/customer-invoices/`. No usar `auth`, `invoices` ni `settings`. `support/` es exclusivamente infraestructura transversal.
|
|
|
|
## Variables y base de datos
|
|
|
|
Copiar `apps/server/.env.e2e.example` a `apps/server/.env.e2e` y completar sus valores locales. Copiar `apps/web/.env.e2e.example` a `apps/web/.env.e2e`.
|
|
|
|
El modo oficial exige `NODE_ENV=test`, `DB_NAME` con prefijo `factuges_erp_e2e_`, `DB_SYNC_MODE=none`, backend en el puerto `3002`, frontend en `http://127.0.0.1:5173` y frontend apuntando a `http://127.0.0.1:3002/api/v1`. Estas validaciones evitan fallbacks a desarrollo.
|
|
|
|
El launcher oficial crea una MariaDB `mariadb:lts-noble` exclusiva con puerto dinámico, credenciales generadas y nombre único; comprueba su readiness y `SELECT 1`. Después prepara el schema mediante la composición modular real del backend y `sequelize.sync()` sin `force`, `alter`, migrations ni SQL manual. El backend posterior recibe la misma DB con `DB_SYNC_MODE=none`, por lo que no la modifica. El launcher destruye exactamente su proyecto Compose al terminar, incluso si falla la preparación o Playwright. No usa la MariaDB remota anterior ni volúmenes persistentes.
|
|
|
|
La preparación P3 crea sólo schema. P4 añade antes de Playwright una cuenta E2E, compañía `factuges-e2e`, membership activa, rol admin y onboarding completado. Usa `E2E_USER_EMAIL` y `E2E_USER_PASSWORD`; no crea customers, suppliers, documentos ni series de escenario. El fichero `fixtures/company-certificates.json` es un JSON vacío versionado para que el backend E2E no dependa de certificados locales.
|
|
|
|
`E2E_USER_EMAIL` y `E2E_USER_PASSWORD` son credenciales locales no versionadas.
|
|
|
|
## Ejecución
|
|
|
|
```bash
|
|
pnpm test:e2e
|
|
pnpm test:e2e:ui
|
|
pnpm test:e2e:headed
|
|
```
|
|
|
|
Los tres comandos oficiales arrancan su propio backend y Vite. Nunca reutilizan procesos existentes: si los puertos `3002` o `5173` están ocupados, la ejecución falla explícitamente.
|
|
|
|
## Modo externo explícito
|
|
|
|
Para depurar contra un stack ya iniciado se debe indicar deliberadamente el destino:
|
|
|
|
```bash
|
|
E2E_BASE_URL=https://e2e.example.test pnpm test:e2e:external
|
|
```
|
|
|
|
También existen `test:e2e:external:ui` y `test:e2e:external:headed`. Sólo estos comandos aceptan `E2E_BASE_URL`; los comandos oficiales lo rechazan.
|
|
|
|
El modo externo no arranca procesos locales ni valida la infraestructura remota: es una herramienta deliberada de debugging y no sustituye al comando oficial.
|
|
|
|
## Selectores
|
|
|
|
Prioridad: `id` técnico estable, `data-testid`, atributo técnico como `name` y CSS estable solo excepcionalmente. No usar textos, labels o `aria-label` traducibles, Tailwind visual, `nth-child` ni DOM incidental. Playwright configura `data-testid`.
|