Top 10 Best Practices for Testing with Cypress
Cypress is a powerful end-to-end (E2E) testing framework that has quickly become a favorite among developers for its speed, intuitive syntax, and strong support for modern web apps. However, in order to utilize the full potential of this automation framework, there are certain best practices that we can follow.
In this blog post, we’ll cover the top 10 best practices for testing with Cypress that will help you write clean, scalable tests, avoid common mistakes, and improve the overall quality of your test suite.
List of Top 10 best practices in Cypress Test Automation
1. Use independent it() blocks
In order to create a good quality test suite, test cases should be independent of each other. In Cypress, we have it() blocks. It is necessary to have multiple it() blocks which are independent of each other. That means if one it() block fails, the other it() blocks should get executed without any blockers. So we have to write our test scripts in such a way that every it() block covers a separate functionality. This allows for better test isolation, leading to less flaky tests and improved test coverage. This also means that the test suite remains reliable even as it grows in complexity in future.
Example:
In the below example, the positive scenario and the negative scenario are written in separate it() blocks, hence they are independent of each other and both are executed without any issues.
describe('Login Page', () => {
it('should login successfully with valid credentials', () => {
cy.visit('/login');
cy.get('#username').type('validUser');
cy.get('#password').type('validPassword');
cy.get('.login-btn').click();
cy.url().should('include', '/dashboard');
});
it('should show error for invalid credentials', () => {
cy.visit('/login');
cy.get('#username').type('invalidUser');
cy.get('#password').type('wrongPassword');
cy.get('.login-btn').click();
cy.get('.error-message').should('be.visible').and('contain', 'Invalid username or password');
});
});2. Reduce Code Duplication using Hooks
Hooks such as before, beforeEach, after and afterEach are used in cypress to handle code duplication and make the code shorter and more efficient. It provides a structured way to setup test conditions which are common across all the test cases. The beforeEach method is commonly used to login into the application before every test case, or reset the navigating url each time before a certain test case runs. Similarly, afterEach method is used to run a cleanup code each time an it() block has finished executing. This ensures that the state of the application becomes clean before starting the execution of the next it() block.
Example:
In the below code, beforeEach is used to navigate to the url and afterEach is used to reset the application state.
describe('User Dashboard Tests', () => {
beforeEach(() => {
// Navigate to the dashboard before each test
cy.visit('/dashboard');
});
it('should display the user profile', () => {
cy.get('.profile').should('be.visible');
});
it('should display recent activity', () => {
cy.get('.activity-feed').should('contain', 'Recent Activity');
});
afterEach(() => {
// Reset the application state after each test
cy.clearCookies();
cy.clearLocalStorage();
});3. Keeping Test Data Separate
In test automation, we often tend to use a huge amount of data. Our scripts have to tirelessly use each set of data and execute the test end-to-end multiple times. Keeping this data secure in a separate file is therefore crucial. Keeping data separate will ensure that the tests are more stable, reliable and maintainable.
In order to do so, create a userData.json file in your project directory, inside “fixtures” folder. Define your test data in key-value pairs as follows:
{
"username":"shoaib"
"password":"abc123"
}And then, you can import the above json file in your cypress code using fixture() command of cypress inside the “before” block (as test data is ideally loaded only once, and that is at the start of the test suite)
describe('Login Test', () => {
let userData;
before(() => {
// Load data from the JSON fixture file before the tests run
cy.fixture('userData').then((data) => {
userData = data;
});
});
it('should login with valid credentials', () => {
cy.visit('/login');
cy.get('#username').type(userData.username);
cy.get('#password').type(userData.password);
cy.get('.login-btn').click();
cy.url().should('include', '/dashboard');
});
});4. Use Custom Attributes to Avoid Flaky Tests
Using custom attributes like data-cy, data-test and data-testid is one of the best practices in cypress. Basically these attributes help locating elements perfectly. This is because attributes like id and classname are prone to changes whenever there are new changes developed in the UI, which can cause the tests to fail regularly. These attributes have to be incorporated by the front end developers into the application to ensure that testers can use them seamlessly in test automation.
Example:
The below is the html code that will have the attribute
<button data-cy="submit-button">Submit</button>
<input data-cy="username-input" type="text" placeholder="Username" />and we use the data-cy attribute now in our CSS selectors in cypress.
describe('Login Test', () => {
it('should log in with valid credentials', () => {
cy.visit('/login');
cy.get('[data-cy="username-input"]').type('testUser');
cy.get('[data-cy="password-input"]').type('securePassword');
cy.get('[data-cy="submit-button"]').click();
cy.url().should('include', '/dashboard');
});
});5. Leverage Cypress Commands for Reusability
This is also one of the strategies to ensure DRY (Don’t Repeat Yourself) while scripting the tests in cypress. Cypress commands are custom commands that you can create to club multiple lines of assertion into a single function. This reduces the code and simplifies the tests.
Example:
In your cypress/support/commands.js file, add the following code to create the login command:
Cypress.Commands.add('login', (username, password) => {
cy.visit('/login');
cy.get('[data-cy="username-input"]').type(username);
cy.get('[data-cy="password-input"]').type(password);
cy.get('[data-cy="submit-button"]').click();
});Then use this custom command in your actual test.
describe('Dashboard Access', () => {
it('should log in and access the dashboard', () => {
cy.login('testUser', 'password123'); // Use the custom login command
cy.url().should('include', '/dashboard');
cy.get('.welcome-message').should('contain', 'Welcome, testUser');
});
});6. Set Base URL in Cypress Configurations
Keeping web url’s inside our cypress code looks very unclean and not organized. Cypress configuration file allows testers to define the base url inside it, which can then be used anywhere in any test case.
Example:
Below is the code changes that needs to be done to define a base url inside the cypress config file.
const { defineConfig } = require('cypress')
module.exports = defineConfig({
e2e: {
baseUrl: 'http://localhost:8484',
},
})Now in our spec file, we just have to specify the /login inside our visit command. Cypress will automatically prepend the localhost url as defined in the config file.
describe('Login Page Test', () => {
it('should visit the login page', () => {
// Visit the login page using a relative URL
cy.visit('/login'); // Cypress will automatically resolve this to 'http://localhost:8484/login'
// Other test steps
cy.get('[data-cy="username-input"]').type('testUser');
cy.get('[data-cy="password-input"]').type('password123');
cy.get('[data-cy="submit-button"]').click();
cy.url().should('include', '/dashboard');
});
});7. Organize Tests by Feature or Workflow
Instead of having one large spec file for E2E test, it is advisable to break down tests into smaller feature-based files. This really makes the scripts easier to debug and improves parallel execution in CI.
/tests
   /login.spec.js
   /signup.spec.js
   /dashboard.spec.js8. Organize Tests by Feature or Workflow
When working with components that contain multiple instances of similar elements, use cy.within() to limit your queries to a specific section. This prevents accidental interactions with unintended elements. Limiting the scope of your test for identification of elements makes your scripts more reliable and less flaky.
Example:
In the below code, we are defining the scope of our element identification for the input field inside the form element.
describe('Form Section Test', () => {
it('should type into the input field and verify the value within .form-section', () => {
cy.visit('/your-page-url');
cy.get('.form-section').within(() => {
cy.get('input').type('Cypress');
cy.get('input').should('have.value', 'Cypress');
});
});
});9. Avoid Hard-Coding Wait Times
Instead of using fixed wait times like cy.wait(5000), use assertions to wait for conditions. Hard-coded waits slow down tests and can make them flaky if the timing varies across environments and elements. We can use should() function to assert for visibility of the element.
10. Chain Multiple Assertions for the Same Element
Instead of running assertions separately, chain them together for efficiency and readability. Cypress allows chaining assertions for the same element, making the code cleaner.
Example:
The below example shows how we can fetch the element, check for its visibility, have certain attributes as well as have some exact value – all these validations in one single line.
cy.get('input[name="email"]')
.should('be.visible')
.and('have.attr', 'type', 'email')
.and('have.value', '');Conclusion
So these were the top 10 best cypress practices that you can utilize to ensure that your cypress tests work smoothly without any issues. These practices improves the overall development and QA process and makes our tests more reliable, sturdy and easy to maintain. Feel free to mention in the comment section if you are aware of any other practices that can help make a difference in the cypress automation space!
