#48 - test(e2e): close coverage gaps — mutation flows, profile, admin - familienarchiv

marcel commented

2026-03-22 19:34:31 +01:00

Owner

Background

A login regression (commit 8f5c13f) was not caught by the E2E suite because the tests were never enforced before push. The bug — handleFetch returning 401 when no auth_token cookie was present, blocking the login action's own credential-validation request — would have been caught immediately by auth.spec.ts had the suite been run. The fix: add a pre-push hook (see companion commit).

A full audit of the app against the existing E2E specs also revealed significant gaps in mutation flows, the profile feature, and the new admin routes.

Coverage gaps

Auth

Login sets a working session — after login(), make an authenticated API call (e.g. GET /api/users/me) and assert 200 OK. Currently auth.spec.ts only checks the URL changed to /; a broken cookie would still pass that assertion.

Documents

Create a document — fill in the new-document form, submit, assert redirect to the detail page and that the title appears
Edit document and save — open an existing document's edit page, change the title, save, assert the new title is shown on the detail page
Upload a file — attach a PDF/image, submit, assert the file preview or download link appears

Persons

Create a new person — fill in first + last name, submit, assert redirect to detail page and name appears

Profile

View profile page — navigate to /profile, assert own username/fields are shown
Update profile fields — change first name, save, assert the updated name appears (e.g. in the nav avatar)
Change password (success) — enter correct current password + new password, save, assert success message, then verify login with new password works
Change password (wrong current) — enter wrong current password, assert error message is shown

Admin

Admin dashboard accessible — navigate to /admin, assert the three tabs (Benutzer, Gruppen, Schlagworte) are visible
Create user via /admin/users/new — fill all fields, submit, assert redirect and new user appears in the list
Edit user via /admin/users/[id] — change a profile field, save, assert success message
Admin password reset — set a new password for another user without entering the current password, assert the user can log in with the new password
Delete user — delete a non-admin user, assert they no longer appear in the list
Create / edit / delete group — full CRUD cycle for a group
Edit / delete tag — rename a tag, assert the new name appears on a document that used it

Permissions

Read-only user cannot see write controls — log in as a read-only user, assert "Neues Dokument", "Neue Person", and edit buttons are absent

Notes

Auth tests already cover wrong credentials, redirect, and logout — those stay as-is.
For destructive tests (delete user/tag), consider a dedicated test user/data fixture or restore state in afterEach.
The auth.setup.ts session trick already shows the right pattern for re-using login state; mutation tests should build on that.

## Background A login regression (commit `8f5c13f`) was not caught by the E2E suite because the tests were never enforced before push. The bug — `handleFetch` returning 401 when no `auth_token` cookie was present, blocking the login action's own credential-validation request — would have been caught immediately by `auth.spec.ts` had the suite been run. The fix: add a pre-push hook (see companion commit). A full audit of the app against the existing E2E specs also revealed significant gaps in mutation flows, the profile feature, and the new admin routes. --- ## Coverage gaps ### Auth - [ ] **Login sets a working session** — after `login()`, make an authenticated API call (e.g. `GET /api/users/me`) and assert `200 OK`. Currently `auth.spec.ts` only checks the URL changed to `/`; a broken cookie would still pass that assertion. ### Documents - [ ] **Create a document** — fill in the new-document form, submit, assert redirect to the detail page and that the title appears - [ ] **Edit document and save** — open an existing document's edit page, change the title, save, assert the new title is shown on the detail page - [ ] **Upload a file** — attach a PDF/image, submit, assert the file preview or download link appears ### Persons - [ ] **Create a new person** — fill in first + last name, submit, assert redirect to detail page and name appears ### Profile - [ ] **View profile page** — navigate to `/profile`, assert own username/fields are shown - [ ] **Update profile fields** — change first name, save, assert the updated name appears (e.g. in the nav avatar) - [ ] **Change password (success)** — enter correct current password + new password, save, assert success message, then verify login with new password works - [ ] **Change password (wrong current)** — enter wrong current password, assert error message is shown ### Admin - [ ] **Admin dashboard accessible** — navigate to `/admin`, assert the three tabs (Benutzer, Gruppen, Schlagworte) are visible - [ ] **Create user via `/admin/users/new`** — fill all fields, submit, assert redirect and new user appears in the list - [ ] **Edit user via `/admin/users/[id]`** — change a profile field, save, assert success message - [ ] **Admin password reset** — set a new password for another user without entering the current password, assert the user can log in with the new password - [ ] **Delete user** — delete a non-admin user, assert they no longer appear in the list - [ ] **Create / edit / delete group** — full CRUD cycle for a group - [ ] **Edit / delete tag** — rename a tag, assert the new name appears on a document that used it ### Permissions - [ ] **Read-only user cannot see write controls** — log in as a read-only user, assert "Neues Dokument", "Neue Person", and edit buttons are absent --- ## Notes - Auth tests already cover wrong credentials, redirect, and logout — those stay as-is. - For destructive tests (delete user/tag), consider a dedicated test user/data fixture or restore state in `afterEach`. - The `auth.setup.ts` session trick already shows the right pattern for re-using login state; mutation tests should build on that.