top of page

Cypress Best Practices : Gears & Brakes

Effective optimization of test automation always begins with the identification of brakes and gears. The brakes refer to the factors that cause delay or slowness while the gears refer to those that bring efficiency into Test Automation and Maintenance


Hence the overall goal of cypress best practices should be

  • To list down gears so that those can be leveraged to increase speed in Automation

  • To list down brakes so that those can be identified and reduced to manage risks w.r.t instability or delay in Test Automation

Gears in Test Automation


Test Execution Gears


Running Headless

Headless Test execution improves the performance by reducing the overhead of rendering UI. For a large number of tests there can be substantial difference in Test Execution time.

npm run cy:run --spec –headless "cypress/e2e/my-spec.cy.js" 


Running in parallel

Running Cypress tests in parallel allows multiple tests to run simultaneously, which can significantly reduce the total execution time of the test suite. Test Parallelization can be achieved in a number of ways in cypress such as the following

  • Leveraging the power of open source tools such as cypress-parallel or cypress-cluster for test distribution, parallelization and reporting.

  • By having multiple instances of cypress running on different ports running different sets of tests

  • By configuring CI/CD pipelines for running different sets of cypress Tests in parallel

Leveraging the power of cypress cache

The "cache" feature in Cypress allows you to cache the browser's data between test runs, reducing the time required to set up the test environment. This can be leveraged in reducing Test execution time.


However it's recommended to clear the cache and rebuild it from scratch if it becomes stale or contains outdated data.


Skipping tests or steps and running only specific tests

Cypress's grep command can be used to skip tests that are not relevant to the changes you are making in the codebase. This can help reduce the overall execution time of the test suite. Similarly conditional logic can be built to skip unnecessary steps from being executed.


Additionally, Cypress provides the "only" command that allows you to run a specific test or suite. This can be helpful when working on a specific test or debugging a test failure.


Pre-loading Test Data using fixtures

Test fixtures can be used to pre-load test data into our application before the test run instead of cypress reading Test data from an external data source during test execution (which is usually expensive).


Use intelligent Stubs and Mocks to simulate data

Use stubs and mocks to simulate the behaviour of external data sources during testing, so that Cypress does not have to rely on actual external sources during testing. Real testing involving all constituent components is important but not for all levels of Testing.


Test Maintenance Gears


Atomic and Independent Tests

Tests should be small, atomic (test only one thing at a time) and independent of each other. Atomic tests are less expensive to maintain.


Fixtures for Test Data

Using fixtures ensure that data is reliable and consistent across tests.


App actions in stead of Page Objects

Cypress recommends actions classes in stead of Page Objects. Page Objects are hard to maintain, fit multiple cases into a uniform interface which is an anti-pattern.


Here is the link to Gleb’s brilliant article comparing Page Objects pattern with App Actions.


Custom DSL(Domain specific language) commands

Cypress’s ability to create custom commands can be leveraged to generate DSL commands corresponding to the organizations. Creating DSL commands will improve code readability and reduce code duplication significantly.


Cypress config to make Tests dynamic

Cypress config can make cypress Tests very dynamic by options like switching of environments, running tests in different browsers, using different test data and URL options.


Brakes in Test Automation


Poor Selectors

Poor selectors can make the tests run slow and indeterministic. XPath selectors are not recommended in Cypress because they are often slow and can be difficult to read and maintain. ID selectors that change frequently or selectors based on position or order are usually not stable and can make the Tests produce incorrect results.


Reading large amount of Test Data

If the application being tested has a large amount of data, loading this data into the test environment can slow down test performance. To improve test performance, consider using fixtures or mocking data to reduce the amount of data loaded into the test environment.


Heavy use of assertions

Large number of assertions can be very expensive. To improve test performance, limit the number of assertions in the test code and use assertions only when necessary to verify test results.


Inefficient wait handling

Overuse of wait commands can slow down test performance, especially if the waits are longer than necessary. To improve test performance, use wait commands only when necessary and set reasonable wait times. Also recommended to handle waits from cypress config (wherever possible) as opposed waiting programmatically from tests.


Slow test set up and Tear down

The setup and teardown code for tests can also impact test performance. If the setup or teardown code takes a long time to run, it can slow down the overall test performance. To improve test performance, optimize the setup and teardown code and consider using hooks to simplify the setup and teardown operations.


Video evidence

Selecting video recording in Cypress can potentially slow down the execution of your tests. When video recording is enabled, Cypress captures video footage of your tests as they run, which can require additional resources and processing time.


Overuse of retries

Overuse of retries can potentially slow down your Cypress tests. Retries in Cypress are a powerful feature that can help make your tests more reliable and robust, but they can also add extra time to your test runs.


To minimize the impact of retries on your test run time, it's a good practice to limit the number of retries to a reasonable number, such as 1-2 retries. Additionally, you should focus on identifying and addressing the root cause of test failures, rather than relying solely on retries to pass flaky tests.


Conclusion

Here are two tables listing down Top gears and brakes in cypress Test Automation





133 views0 comments
bottom of page