Login E2E Tests
E2E tests for sign-in, recovery, registration, token access, and remembered session. They run against the built POS app with the usual Playwright baseline.
Baseline: Preloaded database (test@test.local / test test). The pw stack reloads the DB on startup; tests do not need to clean up users or sessions afterward. Each test uses only seed data or data it creates itself—not state left by another test.
See E2E Testing (Playwright) for environment setup and how to run tests.
Tests in this guide
- valid login — diagram and implementation (new tab)
- invalid login — diagram and implementation (new tab)
- password recovery — diagram and implementation (new tab)
- new user registration — diagram and implementation (new tab)
- access via token — diagram and implementation (new tab)
- automatic access with keep session checked — diagram and implementation (new tab)
Each heading below opens a dedicated page in a new browser tab with the full Mermaid flow and implementation details. This hub keeps only the scenario narratives.
valid login
Someone opens the app and sees the login form. They enter the known test username and password—the same pair that exists in the seeded database—and tap submit.
The test is asking a simple question: does a correct login actually get you in? The form should go away, the submit button should disappear, and the user should land somewhere that looks like “inside the app”: either the user home (add place, no-places warning, etc.) or straight into a place if the seed user already has one. No error banner should appear.
Where it lives: e2e/tests/login.spec.ts — test valid login.
invalid login
Same entry screen, but this time the password is deliberately wrong. The user still taps submit.
The app must not let them through. The login form should stay visible, an error should show (the spec looks for .login-error), and shortcuts into the user area—like add place—must not appear. The story ends with the user still on the login wall, with feedback that something failed.
Where it lives: e2e/tests/login.spec.ts — test invalid login.
password recovery
From the login screen, the user follows the “forgot password” path. They enter an email that matches a real user in the seed data and send the recovery request.
In this stack, a successful response is surfaced as an Ionic modal from the alert service (ion-modal.modal-alert), not a small ion-alert. The test waits for that modal, taps the primary action ([data-id^="modal-alert-button-"]), waits for the modal to go away, and expects the login form to be back. The point is to prove the recovery request completes in a way the user can see and dismiss, end-to-end.
Where it lives: e2e/tests/login.spec.ts — test password recovery.
new user registration
A new person opens the app and chooses registration. They fill a unique email (timestamp-based so runs do not collide), matching passwords, accept the license checkbox, and submit.
The app should create the account and move them forward: the registration UI disappears and they end up in the same family of “logged-in” screens as a normal login (userOrPlaceVisible). The submit control uses [data-id="register-submit-button"] rather than only uppDataId, which the test respects.
Where it lives: e2e/tests/login.spec.ts — test new user registration.
access via token
First act: the user logs in normally so a session token exists (URL query or a localStorage key shaped like the app’s CRC-based token). Second act: a fresh browser page opens the app with ?token=… carrying that value, without typing credentials again.
The story is “magic link” behaviour: the second page should boot, skip the login form, and show the authenticated area. Cookie banners are dismissed if they appear. The test fails if no token could be captured after the first login.
Where it lives: e2e/tests/login.spec.ts — test access via token.
automatic access with keep session checked
The user logs in once, but before submitting they turn on keep session (remember me). After a successful login they do a full navigation back to the app root—as if the browser had been closed and reopened—while the storage profile is preserved.
If persistence works, they should not see the login form again; they should drop straight into the user or place view. The test waits for the SPA to settle and dismisses cookies if needed. It is the automated version of “I ticked stay logged in and tomorrow the app opened already inside.”
Where it lives: e2e/tests/login.spec.ts — test automatic access with keep session checked.