Writing an end-to-end test
Front end engineers use end-to-end (e2e) tests in vets-website
to validate multipage applications with client-side routing. They are primarily used to assert that:
- client applications render their inputs
- client-side navigation occurs when the required fields are populated
End-to-end testing overview
vets-website
uses Cypress to write end-to-end tests. See Cypress Best Practices on VSP and Cypress Resources Reference Guide for detailed use cases and documented helpers/mocks.- Some older end-to-end tests were written in Nightwatch prior to Cypress. All new tests should be written using Cypress moving forward and Nightwatch tests are in the process of being deprecated/migrated to Cypress.
- Refer to the Cypress migration guide to convert old tests or write new tests.
- End-to-end tests are collocated in application folder with the application they test
- Cypress tests can be run using the command
yarn cy:run
(afteryarn watch
toyarn build
).
End-to-end tests conventions
- Use a comment to indicate what page is being tested
- Disable scrolling
- Assert navigation is successful
- Use functions from the helper file to perform all actions on the page
These are recommendations, not requirements, except where labeled as 'REQUIRED'
- Separate navigation from field input
- Use a main test file for navigation, assertions, and calls helpers
- Use a helper file for filling out forms
- Create separate, numbered main test files to organize tests by their focus:
- 00-all-fields.cypress.spec.js - required and optional fields
- 01-required.cypress.spec.js - only required fields
- 02-accessibility.cypress.spec.js - validates accessibility
- 03-auth.cypress.spec.js - validates authentication
- 04-cross-cutting-feature.cypress.spec.js - validates one feature used across several pages (e.g. save in progress)
- Group tests by pages and use a comment to indicate what page is being tested
- Mock all api responses before starting the test. See Mock API responses
- Use
waitForElementVisible
before interacting with any element on the page - Use
Timeouts
constants for setting timeouts (platform/testing/e2e/timeouts.js
) - Use helpers for filling data and performing actions on the page
- (REQUIRED) Perform
axeCheck
on the main body of the application on each page - see axeCheck - Assert that each navigation is successful
Mocking API responses
A mock server runs with the end-to-end tests to allow tests to make production-like calls.
See the Mocks section of Cypress Resources Reference Guide for detailed mock API examples currently used.
Below are some of the commonly used Cypress mocks (accessible from the link above).
- confirmedVA
- confirmedCC
- requests
- cancelReasons
- supportedSites
- facilities
- facilities983
- clinicList983
- slots
- getVAAppointmentMock
- getExpressCareRequestCriteriaMock
- getParentSiteMock
Custom Cypress commands
Cypress supports extending its client api with custom commands.
Below are some of the commonly used custom Cypress commands.
- axeCheck - Callback from a11y check that logs aXe violations to console output.
- expandAccordions - Expands all accordions and AdditionalInfo components.
- injectAxeThenAxeCheck - Combines two common, sequentially called functions.
- login - Simulates a logged in session.
- syncFixtures - Runs task to sync fixtures under a temp path in the Cypress fixtures folder then overwrites
cy.fixture
and the fixture shorthand incy.route
to look for fixtures under that temp path. - upload - Workaround to support file upload functionality in tests, which is currently not officially implemented.
- viewportPreset - Sets the viewport by preset name.
Helpers
The Cypress Resources Reference Guide contains a list of currently utilized Cypress & VAOS Helpers adn Appointment Helpers.