Staging end-to-end suite (Playwright)
AI-generated content
This document was generated by an AI assistant. Verify accuracy before relying on the details.
A Playwright suite that drives the live staging deployment of the Angular application (stage.life-connect.fr, adb-ui 0.68.0) rather than a local build, and records what it actually does. It exists because the React port needs a description of the current behaviour that can be executed: 642 tests over 127 spec files, each naming the capability it proves. It is not a regression suite for the Angular app — it is the reference the rewrite is measured against, and it is the instrument that produced the defect list in test coverage.
At a glance
| Target | the deployed Angular app on staging — not a local server, not a mock |
| Tests | 642 in 128 files (127 specs + the sign-in setup) |
With PW_DESIRED=1 | 671 in 148 files (adds 20 specs that specify fixes) |
| Page objects | 70, under apps/ui/e2e/staging/pages/ |
| Accounts | two, in different organisations — STAGING_ACCOUNT=1 (default) or 2 |
| Credentials | apps/ui/e2e/.auth/staging.env, gitignored, mode 600 |
| Test id attribute | data-cy (set in the config; a standalone script must set it itself) |
| Clean-up | pnpm clean:staging — databases, files bucket and Keycloak (tools/staging-cleanup/README.md) |
Details
Running it
cd apps/ui && set -a; . e2e/.auth/staging.env; set +a
# the session expires in under an hour — refresh it first
STAGING_ACCOUNT=1 ./node_modules/.bin/playwright test \
-c e2e/staging/playwright.staging.config.mjs --project=setup
STAGING_ACCOUNT=1 ./node_modules/.bin/playwright test \
-c e2e/staging/playwright.staging.config.mjs
A single area: append its path (e2e/staging/specs/accounting/). One test: -g "<title>".
Two kinds of spec, and they are deliberately opposed
| where | today | once the defect is fixed | |
|---|---|---|---|
| it records | staging/specs/** | green | red — that is the signal |
| it specifies | staging/specs-desired/** | red | green |
The second set runs only under PW_DESIRED=1, so an ordinary pass stays green. A red default run therefore always means something changed, which is what makes the suite worth watching. When a desired spec turns green, its twin turns red: that is the hand-over, and the recording assertions are deleted in the same commit.
Writing nothing by accident
Staging is shared and this is accounting software, so several mechanisms exist to keep a test run from becoming someone else's problem:
- a run marker.
helpers/run-id.mjsnames every created objecte2e-stg-<n> <what>, so a sweep can tell this suite's residue from real data.assertDeletable()refuses a deletion of anything not carrying it. - record-and-abort.
pages/agency/write-interceptor.mjslets a spec drive an irreversible action all the way to the request, record the payload verbatim, and abort it before it leaves the browser. The payload is stronger evidence than a status code, and the ledger is untouched — with the limit the helper's own header states: it does not prove the server would accept it. - read screens assert they write nothing. Every read-screen test records non-GET traffic and asserts it is empty, because this application has screens that write on navigation.
The index is enforced, not maintained by hand
apps/ui/e2e/feature-index.md carries one row per capability, and apps/ui/test/e2e-feature-index.test.mjs holds eight invariants over it — unique ids, a closed verdict vocabulary, "every claim of coverage names its evidence", "every uncovered row says why", and a ratchet on spec files no row mentions. It has caught its own author twice.
Open questions
- The suite runs by hand today. Moving it into a scheduled GitHub Actions job is planned but not done; the cleanup tooling was deliberately built without a system-binary dependency for the bucket phase so that it can run on a runner.
STAGING_ACCOUNT=2is exercised far less than account 1, and a handful of specs are known to depend on which organisation they run in.