Research guide
How to Run E2E Tests Against Preview/Staging Deployments
Staging and preview deployments are where E2E tests earn their keep — before users see the change. This guide covers per-PR previews, environment configuration, data seeding, and the CI wiring that runs tests against the right URL.
Why staging and previews
Running tests against the build that will ship, rather than a stale environment, catches environment-specific bugs before production. Per-pull-request previews add fast feedback on each change.
A per-PR preview turns a merge decision into a tested one: the exact code about to merge, against real infrastructure, with a real browser.
Point tests at the right environment
Drive the base URL from CI for the environment under test, never hardcode it. The frontend and API base URLs should come from one config that CI sets.
The most common staging bug is the suite that runs against a different environment than the one that deployed.
Seed and isolate data
Use deterministic seed data per run, scoped by worker and pull request, so concurrent previews do not collide. Clean up after the run.
Shared fixtures across parallel previews are a classic source of failures that only appear in the full CI run.
Watch the environment differences
Staging and previews differ from production: feature flags, environment variables, sandboxed third parties, and rate limits. Document what each environment lacks so a staging green is not mistaken for a production green.
Keep the list of differences visible in the run report.
Wire it into CI
Trigger the critical journey set on every pull request against its preview, the fuller set on merge against staging, and the full release set before shipping.
Gate merges on the critical set so a broken journey cannot reach production silently.
What a release run should prove
The release run should prove the critical journeys on the actual build, plus the smoke set, so the deploy decision has fresh evidence.
For the fast liveness checks that belong in every deploy, pair this with the smoke-suite guide.
Preview environments are where agentic journeys earn their keep
Preview and staging deployments are short-lived and change with every pull request, which makes them brutal on fixed locator scripts. Base URLs and seed data already churn per run; the DOM often churns too. An intent-based browser journey that describes the user outcome in plain language adapts to the moving preview UI and re-verifies the expected result, so the same step spec runs against every preview without selector repair between PRs.
Keep deterministic assertions for the stable contracts, then use one or two intent-based journeys for the flow-level proof you want on every preview. That split keeps the preview gate meaningful without turning each PR into a locator-maintenance exercise.
Key takeaways
- Run E2E against the exact build about to ship, not last week’s staging.
- Make base URLs and env config a single source driven by CI, never hardcoded.
- Seed per-run, per-PR data so concurrent previews don’t collide.