Cypress Testing Documentation for DST
Introduction
Why use Cypress?
Cypress allows us to write the following tests, while giving developers access to its interactive GUI
End-to-end tests
Component tests
Integration tests
Unit tests
Grab a coffee while you go through the features of Cypress.
Setup and Installation
Installation Steps
Dev Tests
While on development environment, check if you have the following file setup in the root folder of your local application (refer to the below image)
Common config changes
Put such changes like the viewport height/width settings, etc. directly in the defineConfig
object.
E2E testing config changes
Put changes specific to E2E testing the e2e
object. Following are the current e2e
configs:
e2e: {
baseUrl: 'http://localhost:3000', // base url for e2e testing
excludeSpecPattern: '**/examples/*', // used to exclude tests whose names are filtered by the regex
screenshotOnRunFailure: false, // if true a screenshot folder will be included with all the screen snippets when your tests fail
},
Component testing config changes
Put changes specific to E2E testing the e2e
object. Following are the current e2e
configs:
component: {
devServer: {
framework: 'create-react-app',
bundler: 'webpack',
},
screenshotOnRunFailure: false,
// Defines environment variables for the component tests
env: {
REACT_APP_MAPBOX_API_KEY: 'apiKey',
},
},
For customizing the configuration refer the following:
Cypress Doc link to Configuration File
Writing Tests
Testing Structure
Use the following structure for your test (spec) files:
Describe Blocks: Group related tests.
It Blocks: Define individual test cases.
Assertions: Validate expected outcomes.
For example,
Selectors and Best Practices
Use Data Attributes: Prefer data attributes (
data-cy
) for selecting elements.Avoid Complex Selectors: Use simple selectors to avoid brittle tests.
Custom Cypress Commands
Use the cypress/support/< e2e/component >.js
file to write custom commands for either e2e or component testing.
For example to avoid writing repetitive code to assert an element by id use the custom created command cy.assertByTestId
Running Tests
Open tests in GUI by using the command
To open tests in headless mode (run in terminal without the GUI) run the following command
Debugging and Troubleshooting
Use
cy.debug()
: To pause and inspect the state.View Cypress Logs: Check the logs in the Cypress Test Runner for errors and issues.
Check Network Requests: Use Cypress commands like
cy.intercept()
to monitor network requests.
Best Practices
Keep Tests Independent: Ensure each test runs in isolation.
Use Fixtures for Test Data: Load static data from files. Avoid making API calls from tests, as this will additional load on the servers. Use
cy.intercept
to intercept any type of HTTP call and send back dummy data.Clean Up: Use hooks like
beforeEach
andafterEach
to set up and tear down test states.Write Descriptive Tests: Use clear and descriptive names for test cases and assertions. Begin all test descriptions with
should
.Custom Commands: For repeated DOM queries, use aliases to make tests more readable.
BeforeEach: Use before each for all the repetitive commands within a describe block that is common to all the it blocks
Only assertions in It Blocks: Goal is to keep the It blocks as lean as possible, hence, avoid writing anything other than state management blocks and assertions in the It Blocks. Use the describe block to write all the component mounting and data initialization logic.