-
Notifications
You must be signed in to change notification settings - Fork 53
E2E tests
This page helps guide through running E2E tests locally. E2E/Integration tests are available using Cypress.
To run the integration tests locally, you'll need the following files set up:
frontend/.env.local
/etc/hosts
-
frontend/cypress.env.json
- only required if running with Okta
# /etc/hosts
# add the following line if running with Okta
127.0.0.1 localhost.simplereport.gov
# frontend/cypress.env.json
{
"OKTA_USERNAME": "",
"OKTA_PASSWORD": "",
"OKTA_SECRET": ""
}
You'll also need the following environment variables set for the backend configuration:
SMARTY_AUTH_ID
SMARTY_AUTH_TOKEN
Ask another developer for the Okta and Smarty secrets to populate the environment variables.
Now that you have your environment set up, you are ready for a test run! There are a few ways to run the tests from the cypress
directory, including:
-
yarn e2e:local
- This will open an interactive test runner that lets you select browsers and run your desired specs.
- Prerequisite(s):
- the app must be running locally with the frontend base URL set to
http://localhost:3000
and backend running with the dev profile -
REACT_APP_OKTA_ENABLED=false
infrontend/.env.local
- the app must be running locally with the frontend base URL set to
-
yarn e2e:local:okta
- Same as
yarn e2e:local
, except that specs with a login step will log in to Okta. This is more similar to how the tests run in our GitHub PR workflow. - Prerequisite(s):
- the app must be running locally with Okta with the frontend base URL set to
http://localhost:3000
and the backend running with the okta-local and local profiles -
REACT_APP_OKTA_ENABLED=true
infrontend/.env.local
- the app must be running locally with Okta with the frontend base URL set to
- Same as
Our e2e tests are currently very state-dependent, so here are some things to keep in mind when running:
- tests are expected to be run in order and some specs are dependent on the state produced by previous specs, for example:
-
03-conduct_test_spec.js
uses the patient created in02-add_patient_spec.js
-
04-get_result_from_patient_link_spec.js
uses the patient link generated in03-conduct_test_spec.js
-
08-save_and_start_test_spec.js
uses the patient created in02-add_patient_spec.js
and expects them to not have any tests in progress
-
- our tests expect there to only be 1 facility and will fail if there are multiple facilities for whatever org the test user is authenticated into
- when running the tests with Okta, the test user Cypress McTestUser has admin access to an org with external ID
DAT_ORG
, which with our default sample data will have 2 facilities
- when running the tests with Okta, the test user Cypress McTestUser has admin access to an org with external ID
-
00-health_check.js
is used in our CI to check that the app is up but fails when running locally with either of the commands listed here -
01-organization_sign_up_spec.js
is not re-runnable -
05-self_registration_spec.js
expects the org your test user is in to have a patient registration link generated
See the Cypress documentation for writing new tests. If you need to generate new Wiremock mappings for external services, see this wiki page.
- Getting Started
- [Setup] Docker and docker compose development
- [Setup] IntelliJ run configurations
- [Setup] Running DB outside of Docker (optional)
- [Setup] Running nginx locally (optional)
- [Setup] Running outside of docker
- Accessing and testing weird parts of the app on local dev
- Accessing patient experience in local dev
- API Testing with Insomnia
- Cypress
- How to run e2e locally for development
- E2E tests
- Database maintenance
- MailHog
- Running tests
- SendGrid
- Setting up okta
- Sonar
- Storybook and Chromatic
- Twilio
- User roles
- Wiremock
- CSV Uploader
- Log local DB queries
- Code review and PR conventions
- SimpleReport Style Guide
- How to Review and Test Pull Requests for Dependabot
- How to Review and Test Pull Requests with Terraform Changes
- SimpleReport Deployment Process
- Adding a Developer
- Removing a developer
- Non-deterministic test tracker
- Alert Response - When You Know What is Wrong
- What to Do When You Have No Idea What is Wrong
- Main Branch Status
- Maintenance Mode
- Swapping Slots
- Monitoring
- Container Debugging
- Debugging the ReportStream Uploader
- Renew Azure Service Principal Credentials
- Releasing Changelog Locks
- Muting Alerts
- Architectural Decision Records
- Backend Stack Overview
- Frontend Overview
- Cloud Architecture
- Cloud Environments
- Database ERD
- External IDs
- GraphQL Flow
- Hibernate Lazy fetching and nested models
- Identity Verification (Experian)
- Spring Profile Management
- SR Result bulk uploader device validation logic
- Test Metadata and how we store it
- TestOrder vs TestEvent
- ReportStream Integration
- Feature Flag Setup
- FHIR Resources
- FHIR Conversions
- Okta E2E Integration
- Deploy Application Action
- Slack notifications for support escalations
- Creating a New Environment Within a Resource Group
- How to Add and Use Environment Variables in Azure
- Web Application Firewall (WAF) Troubleshooting and Maintenance
- How to Review and Test Pull Requests with Terraform Changes