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
Comments