What & Why of CYPRESS?

CYPRESS can be used as a software testing tool, based on browser automation for web applications to automate typical user actions. The architectural enhancements in Cypress enable testers to achieve Test-Driven Development (TDD) through full end-to-end testing. The reason behind the development of Cypress is to allow development and testing to happen concurrently. It supports the major browsers like chrome, edge, Firefox, chromium etc. Primarily, cypress uses JavaScript for writing automated test scripts. Comes with it are Chai and Should assertion libraries built into Cypress itself. BDD (Behaviour-driven-development), TDD (Test-driven development). However, Cypress has a built-in test runner which can come in handy while one is doing test execution and debugging but still the same can be controlled by the user via CLI.

1. Whenever you hover over a particular command in Command Log during test execution, cypress framework takes snapshots at that instance so as showing you what exactly happened.

2. In other words there is no adding explicit or implicit wait commands within your tests unlike Selenium that will automatically wait for the commands and assertions made
   

Integration with CUCUMBER

Cucumber is widely used tool which supports and helps in Behavior Driven Development (BDD). Cypress provides integration with Cucumber for writing the test scenarios in BDD format. Cypress uses all the capabilities of Cucumber by using the Cucumber-preprocessor node module. 

Cucumber Feature files

A Feature File is an entry point to the Cucumber tests. This is a file where you will describe your tests in Descriptive language (Like English). It is an essential part of Cucumber, as it serves as an automation test script as well as live documents. A feature file can contain a scenario or can contain many scenarios in a single feature file.

Generating Cucumber.html report with cypress:

With the help of two plugins “cypress-cucumber-preprocessor” and “multiple-cucumber-html-reporter,” we can generate a .html report where we can see the results of the cucumber cypress test case in graphical form (pie chat etc.)

The key to Cucumber is the mapping between Steps and Step Definitions.

Cypress project folder Structure

Cypress: It is the major folder which contains all the tests, required files, supports, plugins.

Fixture: We can use this folder to store our Test Data. We should not hard code data in the test case. Usually the data is stored in JSON format, but it can be driven from an external source like csv, html, JSON, txt etc. Cypress  suggests  to put all  test data in the fixture so that it can be loaded directly in  tests.

Integration: This is the folder we used to write all our test cases under example. We can create a sub-folder under the integration directory and add test’s under that. The test files may be written as .js, .jsx, .coffee and .cjsx. Usually the preferred extension is .js and the test file name format is test-name.spec.js

Support: There are primarily two files inside the support folder

• command.js: It is the file where you add your commonly used functions(Reusable Methods) and custom Commands. Once defined in this file they are automatically available to your test cases. for example you may call to use in tests, such as the login function.

• e2e.js:This file runs before every single spec file/test case. It is a great place to put global configuration and behavior that modifies Cypress like before or before each.

Videos: Cypress records a video for each spec file when running tests during cypress run. Videos are not automatically recorded during cypress open. Videos are stored in the videos folder which is set to cypress/videos by default.

Screenshots: Cypress comes with the ability to take screenshots, whether you are running via cypress open or cypress run. To take a manual screenshot you can use the cy.screenshot() command. The screenshot gets stored in the cypress/screenshots folder by default.

cypress.config.js: When we first time  open Cypress Test Runner, it creates a cypress.config.js file. The cypress.config.js file at the root of your project directory is the default place for your Cypress configurations. We will set all the properties on which and how your cypress test should behave. It is used to pass any configuration values we require, Certain options are set by default in Cypress. We can customize them according to our project.

To identify the default values set by Cypress, navigate to the Settings folder in  Cypress Test Runner

Quick example of config

//set up project configuration in this file
const cucumber = require('cypress-cucumber-preprocessor').default
const report = require('multiple-cucumber-html-reporter');
const { defineConfig } = require("cypress");
const fs = require("fs-extra");
const path = require("path");
const fetchConfigurationByFile = file => {
  const pathOfConfigurationFile = path.join(process.cwd(), `cypress/env`, `${file}.env`) //path of the env file
  return (
    file && fs.readJson(pathOfConfigurationFile));
};
module.exports = defineConfig({
  e2e: {
    setupNodeEvents(on, config) {
      on('after:run', () => {
        report.generate({
          jsonDir: 'cypress/reports/cucumber-json',//path of json file
          reportPath: 'cypress/reports' // path of reports
        });
      });
      on('file:preprocessor', cucumber())
      return fetchConfigurationByFile(config.env.configFile || "qa") || config;  //qa will be the default env if not mentioned.
    },
    specPattern: "cypress/e2e/consumer/**/*.feature", //will refer the featurefiles steps
  }
});

package.json: Package.json is a file which contains the name and its version of all the dependencies that are required in our project. If we look at the devDependencies, it includes cypress as a key and its version.

Best Practices

When it comes to Cypress test automation, there are several best practices to follow to ensure effective and efficient test automation.

Write Isolated Tests: Keep your tests isolated from one another to maintain independence and avoid dependencies between tests. Isolated tests are easier to maintain and debug, and they provide more reliable results.

Use Descriptive Test Names: Choose descriptive and meaningful names for your test cases. Clear test names make it easier to understand the purpose of each test and identify the cause of failures when debugging.

Organize Tests with Test Suites: Group related tests into logical test suites. This helps in organizing and running tests selectively, making it easier to manage and maintain the test suite over time.

Utilize Custom Commands and Cypress Plugins: Leverage custom commands and Cypress plugins to extend the functionality of Cypress. Custom commands allow you to encapsulate frequently used actions and assertions, making your tests more readable and reusable.(eg: Checking the page is loaded when you visit the Home page URL for each testcase)

Implement Page Object Model (POM) Design Pattern: Apply the Page Object Model design pattern to improve test maintainability and reduce code duplication. Separate page-specific logic and interactions into reusable page objects, which encapsulate the elements and actions on a particular page.

Handle Test Data Efficiently: Use fixtures or test data files to manage test data separately from test logic. This ensures that test data can be easily updated or modified without changing the test code itself, making tests more flexible and maintainable.

Use Test Hooks Effectively: Utilize Cypress test hooks such as before, beforeEach, after, and afterEach to set up preconditions, clean up data, or perform necessary actions before and after tests. These hooks allow you to establish a reliable test environment and reduce redundancy in test code.

Run Tests in Headless Mode: Execute tests in headless mode for faster and more efficient test runs, especially in continuous integration (CI) pipelines. Headless mode allows tests to run without a visible browser window, resulting in faster execution and optimized resource usage.

Implement Assertions and Assertions Libraries: Cypress provides a rich set of built-in assertions. These assertions  validate the expected behavior of your application. Additionally, you can integrate popular assertion libraries like Chai or Jest for additional assertion capabilities and flexibility.

Prioritize Test Stability and Reliability: Ensure that your tests are stable and reliable by implementing wait strategies, handling flaky elements, and incorporating explicit assertions. This helps reduce false positives and negatives in your test results and provides more accurate feedback on application behavior.

Regularly Maintain and Update Tests: Keep your test suite up to date by reviewing and maintaining tests regularly. Update tests when there are changes in application functionality, refactor tests to improve readability, and remove obsolete or redundant tests to keep the test suite lean and manageable.

To use cypress with dockers, please refer Cypress meets Docker