E2E tests | VA Platform documentation

Overview

End-to-end (E2E) tests in vets-website verify application behavior in a real browser against a production build. This page describes the E2E testing tech stack and links the E2E child pages.

Which E2E tests run for a given change is decided by test selection — see Test Selection in CI. How E2E tests execute in the CI pipeline (parallelization, container distribution, stress testing) is covered in E2E Tests in CI.

Tech stack

Layer	What we use
Test runner	Cypress
Browser	Chrome, headless (Firefox and Edge are available in the container image)
Execution environment	A Docker container (ECR-hosted Cypress browser image) with Chrome/Firefox/Edge and Node.js pre-installed
App under test	A production build (`vagovprod`), served locally by a test server the workflow starts before the run
Spec pattern	`src//tests//*.cypress.spec.js?(x)`
Global hooks / support	`src/platform/testing/e2e/cypress/support/index.js`
Reporting	Mochawesome JSON via `cypress-multi-reporters` (merged across parallel containers)
Video / screenshots	Video recording on; videos and screenshots archived on failure

How an E2E run is put together

Build — a production build (vagovprod) is produced (or reused) and made available to the E2E job.
Test server — the workflow starts a local test server that serves the build, then waits for a health check to pass before running any specs.
Cypress in Docker — specs run inside the Cypress container against the test server URL, in Chrome, headless.
Results — Mochawesome JSON is produced per container and merged; videos and screenshots are archived on failure for debugging.

Configuration highlights (`config/cypress.config.js`)

Setting	Value	Notes
Default viewport	1920×1080	Desktop-first
`retries.runMode`	2	Failed specs retry up to twice in CI
`retries.openMode`	0	No retries in interactive mode
`video`	on	Recorded for debugging
`includeShadowDom`	true	Web-component support
`chromeWebSecurity`	false	Same-origin policy relaxed for tests

The config also defines mobile / tablet / desktop viewport presets that specs can iterate through. Note: the current preset data is based on December 2022 analytics and is flagged for a future refresh; it does not affect how you write or run tests.

Writing E2E tests

E2E specs live alongside the app they test and follow the *.cypress.spec.js(x) naming convention so both the spec pattern and test selection pick them up. Place them under a tests/ directory within your app (matching src/**/tests/**/*.cypress.spec.js?(x)). A new or changed E2E spec is automatically stress tested on your PR (run repeatedly to check stability) before it's introduced — see E2E Tests in CI.

Child pages

E2E Tests in CI — how E2E tests are selected, distributed across parallel containers, executed, and stress tested in the CI pipeline.