Donkie
17f8b9fee1
Mirrors tests_frontend, but drives the Svelte client instead of the legacy React one: same production image, same PostgreSQL-backed compose stack, same "only the first navigation uses a URL" discipline. - smoke.spec.ts clicks through every top-bar tab, asserting each route's title and the app shell, with no browser console errors; a second test proves the library reached the API rather than falling into its offline state. - crud.spec.ts walks the first-use happy path. client_v2 folds the legacy client's three create forms into one "Add spools" modal, so a manufacturer, a filament and a spool are created by a single submit, then verified back in the library list and on the locations page. Two client_v2-specific helpers earn their keep: the top bar renders its nav twice (desktop + mobile, one hidden by CSS) so nav locators need narrowing to the visible one, and NumberInput's accessible name picks up its stepper and help buttons, so numeric fields are found via their form item instead of getByLabel. The suite publishes on host port 8001 so it can run alongside the legacy one. CI gains a test-frontend-v2 job cloned from test-frontend, gating publish-images alongside it. Also fixes tests_frontend/run.py: it only built client/dist, but the Dockerfile copies client_v2/build unconditionally, so the image could not be built from a clean checkout.
Frontend integration tests (client_v2)
Browser-driven, end-to-end tests for the Svelte client (client_v2), run
against Spoolman as it is deployed for real: the production Docker image
(with the client bundle baked in and served on the same origin as the API)
backed by a real PostgreSQL database.
This is the sibling of ../tests_frontend, which drives the
same deployment with SPOOLMAN_LEGACY_CLIENT=TRUE to cover the legacy React
client. Both complement the backend HTTP suite in
../tests_integration, which never touches the UI.
What is covered
tests/smoke.spec.ts— starting from the app root, clicks through every top-bar tab (locations, labels, settings, back to the library) and confirms each page renders inside the app shell with no browser-console errors. A second test confirms the library actually reaches the API rather than falling into its "couldn't reach the backend" state.tests/crud.spec.ts— the core happy path in one session. client_v2 folds what the legacy client spread over three create forms into a single "Add spools" modal, so one submit creates a manufacturer, a filament and a spool. The result is verified back in the library list (group header, spool row, remaining weight) and on the locations page.
The tests navigate purely through the UI — the top bar to reach each page, the
"Add spools" button to reach the create modal. Only the initial "open the app"
step uses a direct URL. The app's language is forced to English (see
tests/fixtures.ts) so the label and button matchers are stable regardless of
the runner's browser locale.
Running locally
From the repository root:
uv run poe itest-frontend-v2
This builds both client bundles (the image bakes in client_v2/build and, for
the SPOOLMAN_LEGACY_CLIENT fallback, client/dist), builds the
donkie/spoolman:test image, brings up the stack with Docker Compose, waits for
it to become healthy, and runs Playwright. It tears the stack down afterwards.
Useful environment variables:
SPOOLMAN_CONTAINER_ENGINE=podman— run with rootless Podman instead of Docker.SPOOLMAN_HOST_PORT=9000— publish Spoolman on a different host port (default8001, one above the legacy suite's8000so both stacks can be up at the same time).
Running the tests against an already-running instance
If you already have Spoolman running somewhere, you can skip the orchestration and point Playwright straight at it:
cd tests_frontend_v2
npm ci
npx playwright install --with-deps chromium
SPOOLMAN_BASE_URL=http://localhost:8000 npx playwright test
The tests create data with unique, non-ASCII-tagged names, so they are safe to run repeatedly against a persistent instance (though a fresh database is what CI uses).
CI
The test-frontend-v2 job in .github/workflows/ci.yml
reuses the same donkie/spoolman:test image built for the backend integration
tests, so the frontend is verified against the exact artifact that ships.
On failure it uploads the Playwright HTML report as a build artifact.