d1458eb160
Transactions can carry a `notes` field (set via the API — e.g. the currency-conversion metadata on this user's imported historical data), but there was no way to see it in the UI at all. TransactionsTable now shows a note icon next to edit/delete, only when a transaction actually has one, opening a dialog with the text. The edit form's `notes` field was already wired end to end (state, payload) but had no input in the JSX — added it, since a view-only note with no way to edit or clear it would be a dead end. Also fixed e2e/run.sh's readiness check, found while running the full suite for this change: it polled `/` (nginx, answers almost immediately) instead of `/api/health`, so the first test could start before the backend finished migrating/seeding and fail trying to parse nginx's HTML error page as JSON.
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.