formio-automation-fjs

Playwright (TypeScript) against @formio/js — the renderer and the form builder.

Setup, the shared stack, the gate command, running against your own PR, the ratchet and the conventions all live one level up: ../README.md.

pnpm -F formio-automation-fjs pw:component    # the gate — 302 tests, ~8.5 min

To test a change in @formio/js against the build on your own PR rather than the last released image, aim this suite at the PR's review environment:

PR_NUMBER=<your PR> pnpm -F formio-automation-fjs pw:pr:component

The renderer specs mount a form through the portal, so this needs a portal-serving PR (the api-only shape has no portal to drive — the same reason the formio suite's render folder skips there). Check the shape and read what a PR env does differently in Run it against your own PR.

What the gate covers

playwright/tests/component/ — 58 specs that mount the renderer directly: component-setting (22), grid-wizard (22), validations (14). They assert what the renderer does with a form it is handed, with no builder in the way — so when one fails, the defect is in the renderer.

What a healthy run looks like

302 tests · 299 passed · 3 skipped · 0 failed        ~8.5 min

There is no expected-failure list: this gate is meant to be entirely green, and a red is yours until proven otherwise.

The three skips are deliberate and permanent — two preserved describe.skip blocks carried over from the Cypress original (FIO-11505, kept so the gap stays visible rather than disappearing), and an encrypted-at-rest check that reads Mongo directly and therefore only runs against local docker.

What CI runs, and you do not

playwright/tests/e2e/ — 123 specs that build the same forms through the builder UI first (component-setting 43, grid-wizard 34, uswds-tests 23, progress 11, validations 12), plus smoke/ (1). Both suites split the same three ways, so a failure that appears only in e2e usually means the builder or a selector, not the renderer.

Layout

playwright/
├── fixtures/     chained extend: auth → users → poms → env → index
├── pages/        6 page objects
├── setup/        auth setup
├── support/      shared helpers
├── tests/        component (58) · e2e (123) · smoke (1)
└── utils/        16 modules

Environments

| Name | URL | Notes | | --- | --- | --- | | local | http://localhost:3000 | the shared docker stack — what the gate and CI use | | pr | https://pr-<N>.test-form.io | your own PR (portal-serving) — see ../README.md | | hosted | https://portal.test-form.io | hosted portal | | remote_next / remote_dev / remote_previous / remote_latest | remote-*.form.io | deployed environments | | remote_uswds | remote-uswds.form.io | USWDS viewer specs (VPN) |

pnpm run pw:local · pw:hosted · pw:next · pw:uswds · pw:smoke

The USWDS specs cannot run on the local stack — its renderer has no USWDS framework module — so they target the remote environment the team verifies USWDS in. Credentials go in formio-js/.env.uswds; see ../.env.uswds.example.

Worth knowing before you edit a spec

• One spec reads Mongo directly — encrypted-field-advance-logic runs docker exec pw-e2e-test-mongo-1 … mongosh to prove a field is encrypted at rest. It only works against local docker, and the container name follows the shared stack (overridable with PW_MONGO_CONTAINER).
• workers: 1 is the config default; the component gate overrides to 2, which is what CI proved the stack tolerates for that folder.
• File-upload specs need S3 and Google Drive credentials — see ../.env.example; the real values go in formio-js/.env.