E2E Coverage Map
This document tracks the main user-facing flows and whether they are covered by Playwright end-to-end tests.
It is intentionally flow-oriented rather than model-oriented. The goal is to answer:
- Which user promises are protected by E2E tests?
- Which flows still rely only on unit or integration coverage?
- Where should the next Playwright spec go?
Status Meanings
| Status | Meaning |
|---|---|
covered | A Playwright test exercises the main happy path of this flow. |
partial | Some part of the flow is covered, but an important success path or mutation path is still missing. |
missing | No meaningful E2E coverage yet. |
Current Coverage
| Area | User flow | Priority | Status | Spec | Notes |
|---|---|---|---|---|---|
| Auth | Registration page loads | High | covered | frontend/e2e/auth.spec.ts | Basic form smoke coverage. |
| Auth | Register account, receive verification email, verify account, enter app | High | covered | frontend/e2e/registration-with-email-verification.spec.ts | Exercises the real MailHog-backed verification flow. |
| Auth | Login with existing user | High | covered | frontend/e2e/auth.spec.ts | Uses seeded user. |
| Auth | Logout | High | covered | frontend/e2e/auth.spec.ts | Covered as part of login/logout flow. |
| Auth | Protected route redirects unauthenticated user to login | High | covered | frontend/e2e/navigation.spec.ts | Primary auth-guard coverage against /settings/account. |
| Auth | Login failure shows error | Medium | covered | frontend/e2e/navigation.spec.ts | Wrong credentials stay on /login with visible error. |
| Auth | Authenticated user redirected away from /login | Medium | covered | frontend/e2e/navigation.spec.ts | Verified bounce-back to home. |
| Auth | Password reset: request link | High | covered | frontend/e2e/password-reset.spec.ts | Form loads; sends email; shows confirmation with user's address. |
| Auth | Password reset: full flow via email | High | covered | frontend/e2e/password-reset.spec.ts | Request → MailHog capture → follow reset URL → set new password → success → login with new password. |
| Auth | Password reset: invalid token | Medium | covered | frontend/e2e/password-reset.spec.ts | Shows "Invalid Reset Link" with recovery CTA. |
| Navigation | 404 page for unknown routes | Medium | covered | frontend/e2e/navigation.spec.ts | Renders 404 heading, description, and working "Go to Homepage" link. |
| Habits | Create habit, attach pets, and open detail page | High | covered | frontend/e2e/habits.spec.ts | Covers the main owner flow from list page creation through navigation to the created habit detail. |
| Habits | Log habit activity for a day and keep it after reload | High | covered | frontend/e2e/habits.spec.ts | Uses the day dialog on the detail page and verifies the saved state persists after page reload. |
| Habits | Edit habit settings | High | covered | frontend/e2e/habits.spec.ts | Verifies updating the habit name from the detail-page edit dialog. |
| Habits | Archive and restore habit | Medium | covered | frontend/e2e/habits.spec.ts | Exercises both archive and restore from the owner detail flow. |
| Habits | Delete habit | High | covered | frontend/e2e/habits.spec.ts | Confirms deletion through the destructive dialog and return to the habits list. |
| Pets | Add pet with minimal required fields | High | covered | frontend/e2e/pet-creation.spec.ts | Core happy path exists. |
| Pets | Add pet validation feedback | Medium | covered | frontend/e2e/pet-creation.spec.ts | Good smoke-level validation coverage. |
| Pets | Add pet with different pet type | Medium | covered | frontend/e2e/pet-creation.spec.ts | Covers cat and dog creation paths. |
| Pets | Queue offline pet creation and replay on reconnect | High | covered | frontend/e2e/offline-mode.spec.ts | Verifies offline create shows queued state, then syncs to a real pet profile link after reconnect. |
| Pets | Edit pet general info | High | covered | frontend/e2e/pet-basic-lifecycle.spec.ts | Uses the inline profile editor on the General tab. |
| Pets | Queue offline pet edit and replay on reconnect | High | covered | frontend/e2e/offline-mode.spec.ts | Confirms optimistic offline edit persists after reconnect and reload. |
| Pets | Delete pet | High | covered | frontend/e2e/pet-basic-lifecycle.spec.ts | Uses the Status tab danger zone and confirm dialog. |
| Pets | Queue offline pet deletion and replay on reconnect | High | covered | frontend/e2e/offline-mode.spec.ts | Confirms offline removal hides the pet immediately and stays deleted after reconnect. |
| Pets | Cold-start offline with cached auth into pet management | High | covered | frontend/e2e/offline-mode.spec.ts | Verifies cached session survives reload while offline and pet create remains reachable. |
| Medical records | Queue offline medical record create and replay on reconnect | High | covered | frontend/e2e/offline-mode.spec.ts | Confirms optimistic offline create persists after reconnect and reload. |
| Habits | Queue offline habit day check-in and replay on reconnect | High | covered | frontend/e2e/offline-mode.spec.ts | Uses habit detail day dialog; verifies saved check-in survives reconnect and reload. |
| Pet photos | Upload pet profile photo | High | covered | frontend/e2e/pet-photos.spec.ts | Uses the inline General tab editor upload control. |
| Pet photos | Add extra gallery photo | High | covered | frontend/e2e/pet-photos.spec.ts | Confirms the pet reaches a multi-photo state in the real browser flow. |
| Pet photos | Set gallery photo as primary/avatar | Medium | covered | frontend/e2e/pet-photos.spec.ts | Uses the avatar modal action on a non-primary photo. |
| Pet photos | Delete pet photo | High | covered | frontend/e2e/pet-photos.spec.ts | Deletes through the avatar modal and verifies the gallery count updates. |
| Weight records | Add weight record | High | covered | frontend/e2e/pet-health.spec.ts | Uses the inline add form and edit-mode list. |
| Weight records | Edit weight record | Medium | covered | frontend/e2e/pet-health.spec.ts | |
| Weight records | Remove weight record | High | covered | frontend/e2e/pet-health.spec.ts | |
| Vaccinations | Add vaccination record | High | covered | frontend/e2e/pet-health.spec.ts | Covers the main upcoming vaccination flow. |
| Vaccinations | Edit vaccination record | Medium | covered | frontend/e2e/pet-health.spec.ts | |
| Vaccinations | Remove vaccination record | High | covered | frontend/e2e/pet-health.spec.ts | |
| Medical records | Add medical record | High | covered | frontend/e2e/pet-health.spec.ts | |
| Medical records | Edit medical record | Medium | covered | frontend/e2e/pet-health.spec.ts | |
| Medical records | Remove medical record | High | covered | frontend/e2e/pet-health.spec.ts | |
| Medical records | Add or remove medical record attachment photo | Medium | covered | frontend/e2e/pet-health.spec.ts | Uses the medical form attachment control and deletes through the health-record photo modal. |
| Microchips | Add microchip | High | covered | frontend/e2e/pet-health.spec.ts | |
| Microchips | Edit microchip | Medium | covered | frontend/e2e/pet-health.spec.ts | |
| Microchips | Remove microchip | High | covered | frontend/e2e/pet-health.spec.ts | |
| Pet people | Generate invitation link | High | covered | frontend/e2e/pet-people.spec.ts | Covers creating a role-scoped share link from the People section. |
| Pet people | Revoke or remove invitation link | High | covered | frontend/e2e/pet-people.spec.ts | Covers revoking a pending invitation from the People section. |
| Pet people | Accept invitation after authentication redirect | High | covered | frontend/e2e/pet-people.spec.ts | Covers invite page redirect to login, return to invite page, and successful acceptance. |
| Profile | Upload avatar | Medium | covered | frontend/e2e/profile.spec.ts | Includes invalid-file and size validation. |
| Profile | Replace avatar | Medium | covered | frontend/e2e/profile.spec.ts | |
| Profile | Remove avatar | Medium | covered | frontend/e2e/profile.spec.ts | |
| Profile | Change password | Medium | partial | frontend/e2e/profile.spec.ts | Dialog and validation are covered; the full success path remains unit-level coverage. |
| Profile | Edit profile details | High | covered | frontend/e2e/profile.spec.ts | Covers the real account name-edit flow and persistence after reload. |
| Profile | Set real email for Telegram placeholder account and verify it | High | covered | frontend/e2e/profile.spec.ts | Covers email entry, confirmation dialog, verification email, and successful verification. |
| Messages | Send a message in an existing conversation | High | missing | — | The page-level MSW test covers sending and rendering the returned message; no seeded two-user E2E journey exists yet. |
| Notifications | Open notification list and mark a notification read | Medium | missing | — | The /notifications page has MSW coverage for empty/list/read states; settings preferences are covered separately. |
| Helper profiles | Create helper profile | High | covered | frontend/e2e/helper-profile-creation.spec.ts | Covers the authenticated create flow and redirect to the created profile. |
| Helper profiles | Public helpers listing shows only publicly visible profiles | High | covered | frontend/e2e/helper-profile-creation.spec.ts | Confirms seeded approved helpers appear on /helpers, newly created public helpers appear immediately, and private helpers stay hidden. |
| Helper profiles | Public helper detail page is accessible only for publicly visible items | High | covered | frontend/e2e/helper-profile-creation.spec.ts | Confirms seeded approved helpers open on /helpers/:id, newly created public helpers open immediately, and private helpers return public 404. |
| Groups | Open groups list, group detail, and settings | High | covered | frontend/e2e/groups.spec.ts | Creates a group via API after login, then walks list → detail → settings with stable headings and URL checks. |
| Finances | Open finance workspace and create an expense | High | covered | frontend/e2e/finance.spec.ts | Uses the seeded demo ledger; account/category panel mutation paths are covered with Vitest and MSW. |
| Placement | Owner creates a permanent placement request and finds it in discovery | High | covered | frontend/e2e/placement.spec.ts | Creates an owned pet through authenticated API setup, then exercises the real placement UI and /requests routes. |
Recommended Spec Layout
Keep specs organized by user journey instead of by backend resource or component.
Recommended target structure:
| Spec | Primary responsibility |
|---|---|
frontend/e2e/smoke.spec.ts | Deployment-level root-page and document-title smoke check. |
frontend/e2e/auth.spec.ts | Register-page smoke, login, and logout. |
frontend/e2e/registration-with-email-verification.spec.ts | Successful registration and verification journey, plus a small number of failure states. |
frontend/e2e/pet-creation.spec.ts | Creating pets and create-form validation. |
frontend/e2e/pet-basic-lifecycle.spec.ts | Edit pet general info and delete pet. |
frontend/e2e/offline-mode.spec.ts | Offline pet create/edit/delete, medical record create, and habit day check-in queue/replay across reconnect. |
frontend/e2e/pet-photos.spec.ts | Upload gallery photo, set primary photo, delete photo. |
frontend/e2e/pet-health.spec.ts | Weight, vaccination, medical record, and microchip CRUD happy paths. |
frontend/e2e/pet-people.spec.ts | Invitation link creation and removal in the People section. |
frontend/e2e/profile.spec.ts | Profile details, email verification, avatar management, and password-dialog validation. |
frontend/e2e/helper-profile-creation.spec.ts | Helper profile creation plus public-directory visibility and public-detail access rules. |
frontend/e2e/navigation.spec.ts | 404 page, auth guard redirects, login-when-authenticated bounce, login failure. |
frontend/e2e/password-reset.spec.ts | Forgot-password form, full reset flow via MailHog email, invalid token error. |
frontend/e2e/habits.spec.ts | Habit creation, day logging, editing, archiving/restoring, and deletion. |
frontend/e2e/groups.spec.ts | Groups list → detail → settings happy path for an owned group. |
frontend/e2e/finance.spec.ts | Seeded finance workspace and expense-creation happy path. |
frontend/e2e/placement.spec.ts | Owner placement-request creation, detail redirect, and discovery listing. |
Messages and the /notifications page currently stop at page-level Vitest + MSW coverage, so they intentionally have no Playwright spec in this table yet.
Good Testing Practice For This Stack
Prefer one true auth journey, then authenticated setup
For this stack, it is better to:
- keep a small number of explicit auth tests that really verify login, logout, registration, and redirect behavior
- avoid repeating full UI login in every unrelated test
- use authenticated Playwright setup for the rest of the suite
Why this fits here:
- login is already subject to rate limiting
- repeated UI auth makes the suite slower and more fragile
- your existing helper pattern already hints at this problem
The main exception is when login is part of the product promise being tested, such as:
- redirecting an unauthenticated user back into a protected flow
- invitation acceptance that depends on authentication
- post-registration onboarding
Prefer happy-path CRUD in E2E, edge cases elsewhere
For pet records and profile editing:
- use E2E for the main browser journey and one destructive path
- keep deep validation matrices in component, integration, or backend tests
That gives you confidence without turning Playwright into the slowest possible test layer.
Suggested Next Implementation Order
- Decide whether verified-user email-change rejection needs its own E2E, or should remain backend/integration coverage only.
- Revisit whether invitation decline deserves E2E coverage or can stay below the browser layer.
- Add admin route access guard tests (non-admin blocked from admin routes).
Maintenance Rule
When a new user-facing feature ships:
- Add or update the flow in this file.
- Mark whether E2E coverage is required.
- Link the spec once coverage exists.
This keeps the document lightweight and makes coverage gaps obvious during feature work.