E2E Testing (Playwright)

End-to-end tests run against the built application using Playwright. Tests live in unpispas.nx (e2e/tests/) and can run against the nx stack or the isolated pw stack.

Overview

E2E tests live in e2e/tests/ and are executed from the monorepo root. The HTML report is written to docs/e2e/report/ when using the pw stack and can be served at doc.pw.{domain}/e2e/report/.

Which Docker context to use

This monorepo uses two compose stacks for different jobs:

Task	Stack / service
Angular builds, Nx, upp-guide (Docusaurus), unit tests, npm in /app	nx-dev in docker/nx — e.g. cd docker/nx && docker compose exec nx-dev bash -c "cd /app && npx nx build unpispas-pos"
Playwright E2E (recommended), pw DB reset (deploy-ddbb / datacontent)	docker/pw — npm run e2e:up, npm run e2e:reset-db, npm run e2e:run, or ./rune2e.sh (these call docker compose and run inside playwright or php-fpm)

Agent-oriented detail lives in the repo under .cursor/rules/docker-dev-environment.mdc and .cursor/context/e2e-howto/execution.md (keep this page aligned when those change).

Environment

E2E tests run in an isolated stack (docker/pw): own database, frontend, backend, and Playwright. Subdomain pw: app.pw., api.pw.. The frontend serves config.js generated at startup so the app uses the pw stack API.

The stack is designed to stay up while tests are executed repeatedly. The startup cost is paid once; test runs focus on state reset + Playwright execution.

Automation rules

• Persistent stack: Start docker/pw once and keep it alive during development.
• Reset-driven execution: Restore deterministic baseline state with npm run e2e:reset-db (or e2e:reset-env) before running tests.
• Independence: Tests must not depend on previous test leftovers or execution order.
• Scenario data: The reset command restores only baseline. Each test creates any extra data it needs.

Prerequisites

1. docker/proxy running (ports 80/443)
2. App must be built inside nx-dev (see Which Docker context to use above), e.g. cd docker/nx && docker compose exec nx-dev bash -c "cd /app && npx nx build unpispas-pos" — then use your usual process so the pw frontend can serve the build if required.
3. server/.env with BUILD_DDBB_HOST=db and credentials matching docker/pw/.env
4. DNS/hosts: app.pw.unpispas4.mywire.org and api.pw.unpispas4.mywire.org resolve to the host

Running E2E Tests

E2E tests run from the unpispas.nx monorepo. Each stack is self-contained.

Project order (Chromium): npm run e2e:run and ./rune2e.sh (without extra args) run setup-chromium + chromium first, then chromium-login, so the shared pw database is not mutated by login/registration flows before catalog or product-chain specs. A bare npx playwright test in the container may schedule chromium-login before chromium and break those specs—prefer e2e:run / rune2e.sh for the full suite.

Full pw stack (recommended)

npm install
npx playwright install
npm run e2e:up
npm run e2e:reset-db
npm run e2e:run

Against running nx stack (no pw stack)

BASE_URL=https://app.nx.unpispas4.mywire.org/unpispas-pos/ npm run test:e2e

Manual execution (pw stack)

cd docker/pw
docker compose up -d
docker compose exec -T php-fpm bash -lc "cd /usr/share/nginx/html && php ddbb/deploy-ddbb.php && php ddbb/datacontent.php"
docker compose exec -T playwright npx playwright test e2e/tests/smoke.spec.ts

# Run only Chromium
docker compose exec -T playwright npx playwright test --project=chromium

# Run with UI mode (interactive)
docker compose exec playwright npx playwright test --ui

Report

After each run, the HTML report is generated in docs/e2e/report/. Open index.html locally or visit doc.pw.{domain}/e2e/report/ when the pw documentation container is running.

Results: Ver reporte E2E — also available from Other Resources.

Test Documentation

Scenario guides describe what each test is for in plain language: a short story (who the user is, what they do, what success means) plus where the test lives in the repo (file and test name). Login, Place, Product, and Catalog E2E hubs link to dedicated detail pages (shared setup where needed + per scenario: full Mermaid flow and implementation). Open those from each hub in a new tab via the title links. Smoke below stays on this page only.

Area	Guide
Place	Place E2E Tests
Login	Login E2E Tests
Product edition	Product E2E Tests
Catalog management	Catalog E2E Tests

Smoke

You hit the app URL cold—no login helper, no reset step in the spec itself. The page should at least be the SPA, not a directory listing: it gets a real document title, and within a few seconds you see one of the main entry states: the login submit control, add place, or the no places warning.

That is the whole smoke test: “can we load the bundle and reach a recognizable first screen?” It does not assert a specific user or mutate the database.

Where it lives: e2e/tests/smoke.spec.ts — test app loads and shows root content.