danvics/familynido
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
familynido/web/familynido-web/e2e
History
Pablo Fernández a308041d59 Initial commit 
FamilyNido — a self-hosted PWA for a single household: shared calendar,
chores, meals, school agenda, health records and a family wall. One
instance per family, deployable with `docker compose` on any home
server.

Stack: .NET 10 (ASP.NET Core Minimal APIs) + EF Core 10 + PostgreSQL 16
on the backend, Angular 21 (standalone, signals, zoneless) + Tailwind
CSS v4 on the frontend, SignalR for realtime, optional OIDC alongside
local credentials, integration via a versioned `/api/v1/**` public API.

See README.md for the module overview and how to deploy.
2026-05-13 00:23:14 +02:00
..
a11y.spec.ts Initial commit 2026-05-13 00:23:14 +02:00
account-language.spec.ts Initial commit 2026-05-13 00:23:14 +02:00
auth-b.setup.ts Initial commit 2026-05-13 00:23:14 +02:00
auth.setup.ts Initial commit 2026-05-13 00:23:14 +02:00
calendar.spec.ts Initial commit 2026-05-13 00:23:14 +02:00
dashboard.spec.ts Initial commit 2026-05-13 00:23:14 +02:00
fixtures.ts Initial commit 2026-05-13 00:23:14 +02:00
i18n.spec.ts Initial commit 2026-05-13 00:23:14 +02:00
invitations.spec.ts Initial commit 2026-05-13 00:23:14 +02:00
meals.spec.ts Initial commit 2026-05-13 00:23:14 +02:00
multi-user-tasks.b.spec.ts Initial commit 2026-05-13 00:23:14 +02:00
README.md Initial commit 2026-05-13 00:23:14 +02:00
shell.spec.ts Initial commit 2026-05-13 00:23:14 +02:00
tasks.spec.ts Initial commit 2026-05-13 00:23:14 +02:00
wall.spec.ts Initial commit 2026-05-13 00:23:14 +02:00

README.md

FamilyNido E2E tests (Playwright)

Smoke tests for the four critical user flows: app shell + nav, task create/complete, wall publish, dashboard widgets. They target a running deployment — the suite does not start the API or the database.

Prerequisites

  1. A running FamilyNido instance. Either the dev compose (docker compose -f deploy/docker-compose.dev.yml up -d) or the prod stack on a real domain.
  2. A test user with a local password. PocketID flows aren't scriptable from Playwright, but the local-credentials login (POST /api/auth/local/login) is. Set up the user once via the regular UI:
    • Log in via PocketID with the user you'd like to use for tests.
    • Go to /account → "Establecer contraseña local" and pick a password.
  3. Browsers installed by Playwright. First time only: 
    npx playwright install --with-deps chromium

Configuration

Set three env vars (or put them in a .env.e2e consumed by your shell):

export E2E_BASE_URL=http://localhost:5173
export E2E_USER_EMAIL=tu-email@example.com
export E2E_USER_PASSWORD=elPasswordQueAcabasDePoner

E2E_BASE_URL defaults to http://localhost:5173 (the dev server proxy) when unset.

Running

# All tests, headless
npm run e2e

# With Playwright's UI for debugging
npm run e2e:ui

Each spec is idempotent — tasks and wall posts created during a run are also cleaned up at the end. Re-running the suite back-to-back should always pass.

Layout

e2e/
  auth.setup.ts      # Fires once before every project; logs in via API.
  shell.spec.ts      # /home + every primary tab loads.
  tasks.spec.ts      # Create + complete + archive.
  wall.spec.ts       # Publish + delete.
  dashboard.spec.ts  # Widget grid mounts.
  .auth/state.json   # Generated; .gitignored. Don't commit.

Adding new tests

  • Stay idempotent: any data the test creates must be removed by its end.
  • Prefer role-based locators (getByRole, getByPlaceholder) over CSS classes — they survive Tailwind churn better.
  • If a test needs admin-only privileges, document it; the test user must be Admin for now (we don't model multiple test identities yet).