75dd43c8e3
Theme previously followed only the OS's prefers-color-scheme, which switches automatically on this user's Mac at sunset/sunrise. Adds an explicit override in Settings: Light/Dark/System, System being the previous (default) auto-follow-the-OS behavior. Persisted client-side in localStorage (lib/theme.ts, same pattern as language) rather than server-side like currency — it's a pure display preference, and synchronous localStorage reads are what make the anti-FOUC inline script in index.html possible. index.css already had the [data-theme] CSS variables laid in ahead of time; only the JS to actually set the attribute, and the Settings UI, were missing. Covered by 2 new Playwright specs (theme-switcher.spec.ts) run against the isolated e2e stack: explicit choice overrides a dark OS and survives reload; switching back to "system" doesn't leave a stale forced theme.
E2E tests
Playwright driving a real browser against a real, fully isolated Aurum stack — not the self-hosted instance you actually use day to day. These tests create and read real data over the real HTTP API and real rendered UI, which is the only way to actually catch things like a CSS layout overflow or a filter that's silently ignored — a backend-only test suite can't see either.
Isolation
run.sh brings up a second, throwaway stack alongside your real one:
| real instance | e2e stack | |
|---|---|---|
| compose project | aurum (default) |
aurum-e2e |
| Postgres database | aurum |
aurum_e2e |
| web port | 3000 | 3100 |
Different project name means different containers, network, and — crucially
— a different named Postgres volume, so the e2e Postgres data directory is
physically separate from aurum_pgdata. run.sh always tears the e2e stack
down with docker compose down -v on exit (even on failure/Ctrl-C), so no
test data is left behind and your real instance is never touched, restarted,
or read from.
Running
cd e2e
./run.sh
Pass extra Playwright CLI args through, e.g. to run one file or open the trace viewer on failure:
./run.sh tests/year-switcher.spec.ts
./run.sh --headed
Adding a test
- Seed data via the
requestfixture and the helpers intests/helpers.ts(hits/api/...directly — fast and doesn't depend on clicking through a form). Then drive the actual page for the behavior under test. - Tests run with
workers: 1against one shared backend/DB within a singlerun.shinvocation, so give each spec's seeded data a distinct year/month (or otherwise non-overlapping scope) rather than relying on a clean slate between spec files.