Place E2E Tests
E2E tests for creating and editing a place (local): opening the form, filling the name, and walking through address validation when the environment allows it.
To create the first place, the account must be active (email already validated). If the user is inactive, the UI shows the activation warning and blocks creation.
Baseline: Preloaded database (test@test.local / test test). The pw stack reloads the DB on startup; no post-test cleanup is required. Tests must not assume another test ran first.
See E2E Testing (Playwright) for environment setup and how to run tests.
Tests in this guide
- Setup — shared
place-createbeforeEach — diagram and implementation (new tab) - place creation form opens and name can be filled — diagram and implementation (new tab)
- place creation completes with address — diagram and implementation (new tab)
Each heading below opens a dedicated page in a new browser tab for Setup or the scenario flow. This hub keeps only the narratives.
Setup (place-create beforeEach)
Shared bootstrap for both tests in place-create.spec.ts: force navigator.onLine, load the SPA, dismiss cookies, then reach user home (add place / no-places visible). If the seed opens straight into a place, the flow steps back to the user view first. Open Setup — diagram and implementation.
place creation form opens and name can be filled
The test always starts from a logged-in user on the user home after the shared beforeEach. From there, the user taps Add place (or the no-places card—both entry points are wired). The place editor appears. They type a name, “E2E Test Local”, and the test only checks that the field accepts and keeps that value. No place is saved; the scenario stops at “the create form is real and the name field works.”
Where it lives: e2e/tests/place-create.spec.ts — test place creation form opens and name can be filled.
place creation completes with address
Same entry path and beforeEach as above. The user opens add-place, sets the name, then opens the address section. They fill street, number, and locality and tap validate. That step talks to geocoding when a Google Maps key is available.
Two endings are acceptable, and the test encodes both. Happy path: validation succeeds, they confirm the suggested address, the modal closes, submit becomes enabled, they save, and ideally the editor closes—place created. Without geocoding (typical in some CI setups): validation never offers a confirm button; the user closes the address modal and the test still insists the main form is visible and usable. Either way, the story is “address flow does not brick place creation,” not “geocode must always succeed.” If you need the exact waits, WebKit timeout, and overlay handling for automation, the linked detail page spells them out step by step.
Where it lives: e2e/tests/place-create.spec.ts — test place creation completes with address.