bermudalambandClaude Opus 5
6a90e957f2
The e2e suite ran against the development database and nothing truncated it. Every run seeded more fixtures and left them, so the unfiltered storefront grew monotonically — 1,662 items by the time #186 was filed — until rendering it outran the assertions' timeouts. It failed locally, passed in CI where the database is fresh, and got steadily worse, which is the combination nobody can act on. start-local.ps1 -E2eDb runs the stack against a separate container on a separate port with tmpfs storage, so it starts empty every time. Migrations already run on every start, so an empty volume is a working one. The development database is untouched, so anything set up there by hand survives. Deliberately a third database rather than sharing either existing one. The integration suite truncates between tests, so an e2e run sharing with it would have its fixtures deleted underneath it (#116) — different container, different port, different credentials, so the mistake is impossible rather than discouraged. Verified by recreating the database from the compose file, confirming it came up with zero items, and running the full suite against it: 157 of 157. An earlier attempt at this reported 23 passed and 53 not run, which was worthless — a stale backend from a previous run still held port 3000 and was talking to a database I had already deleted. The port is checked before the run now, and the same mistake produced a wrong rate-limiter measurement earlier in this work. Pagination is the other half of #186 and is filed separately: a shop that renders its whole catalogue in one page is worth fixing on its own merits, not as a side effect of a test fix. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
40 lines
1.8 KiB
YAML
40 lines
1.8 KiB
YAML
# A throwaway Postgres for the end-to-end suite.
|
|
#
|
|
# The e2e suite used to run against the development database that
|
|
# start-local.ps1 brings up, and nothing ever truncated it: every run seeded
|
|
# more fixtures and left them. The unfiltered storefront grew monotonically —
|
|
# 1,662 items by the time #186 was filed — until rendering it outran the
|
|
# assertions' timeout. It failed locally, passed in CI where the database is
|
|
# fresh, and got slowly worse, which is the combination nobody can act on.
|
|
#
|
|
# Deliberately a mirror of docker-compose.test.yml rather than a shared file.
|
|
# The two suites must not share a database: the integration suite truncates
|
|
# between tests, so running it while an e2e run is in flight would delete that
|
|
# run's fixtures underneath it (#116). Different container, different port,
|
|
# different credentials — so the mistake is impossible rather than discouraged.
|
|
#
|
|
# tmpfs, like the integration database: the data is worthless the moment the
|
|
# run ends, and a container with nothing to persist starts faster and cannot
|
|
# accumulate anything between runs.
|
|
#
|
|
# docker compose -f backend/docker-compose.e2e.yml up -d
|
|
# docker compose -f backend/docker-compose.e2e.yml down
|
|
#
|
|
# The suite and the application both have to point at it. See
|
|
# scripts/start-local.ps1 -E2eDb, which does that for you.
|
|
services:
|
|
redefined-designs-e2e-db:
|
|
image: postgres:16
|
|
container_name: redefined-designs-e2e-db
|
|
environment:
|
|
- POSTGRES_USER=redefined_e2e
|
|
- POSTGRES_PASSWORD=redefined_e2e
|
|
- POSTGRES_DB=redefined_e2e
|
|
ports:
|
|
# Not 55432 (integration) and not 55500 (development). Override with
|
|
# E2E_DB_PORT if Hyper-V has reserved this one — it silently claims
|
|
# ranges on Windows, which is why the integration suite has TEST_PGPORT.
|
|
- "${E2E_DB_PORT:-55501}:5432"
|
|
tmpfs:
|
|
- /var/lib/postgresql/data
|