Cypress and TypeScript: A Dynamic Duo for Web Application & API Automation

by Yogesh Dhole | Mar 26, 2025 | Blog

Introduction to Cypress and TypeScript Automation:

Nowadays, the TypeScript programming language is becoming popular in the field of testing and test automation. Testers should know how to automate web applications using this new, trending programming language. Cypress and TypeScript automation can be integrated with Playwright and Cypress to enhance testing efficiency. In this blog, we are going to see how we can play with TypeScript and Cypress along with Cucumber for a BDD approach.

TypeScript’s strong typing and enhanced code quality address the issues of brittle tests and improve overall code maintainability. Cypress, with its real-time feedback, developer-friendly API, and robust testing capabilities, helps in creating reliable and efficient test suites for web applications.

Additionally, adopting a BDD approach with tools like Cucumber enhances collaboration between development, testing, and business teams by providing a common language for writing tests in a natural language format, making test scenarios more accessible and understandable by non-technical stakeholders.

In this blog, we will build a test automation framework from scratch, so even if you have never used Cypress, Typescript, or Cucumber, there are no issues. Together, we will learn from scratch, and in the end, I am sure you will be able to build your test automation framework. 

Before we start building the framework and start with our discussion on the technology stack we are going to use, let’s first complete the environment setup we need for this project. Follow the steps below sequentially and let me know in the comments if you face any issues. Additionally, I am sharing the official website links just in case you want to take a look at the information on the tools we are using. Check here,

• Cucumber – https://cucumber.io/
• Node – https://nodejs.org/en
• Cypress – https://www.cypress.io/
• TypeScript Documentation – https://www.typescriptlang.org/docs/
• Allure Reports – https://allurereport.org/

Setting up the environment:

The first thing we need to make this framework work is Node.js, so ensure you have a node installed on the system. The very next thing to do is to have all the packages mentioned above installed on the system. How can you install them? Don’t worry; use the below commands.

• Ts-Node: npm i typescript
• Cypress: npm install cypress –save-dev
• Cucumber: npm i @cucumber/cucumber -D
• Allure Command Line: npm i allure-commandline
• Cucumber per-processor: npm install –save-dev cypress-cucumber-preprocessor
• Tsify: npm install tsify
• Allure Combine: npm i allure-combined

So far, we have covered and installed all we need to make this automation work for us. Now, let’s move to the next step and understand the framework structure.

Framework Structure:

Let’s now understand some of the main players of this framework. As we are using the BDD approach assisted by the cucumber tool, the two most important players are the feature file and the step definition file. To make this more robust, flexible and reliable, we will include the page object model (POM). Let’s look at each file and its importance in the framework.

Feature File: 

Feature files are an essential part of Behavior-Driven Development (BDD) frameworks like Cucumber. They describe the application’s expected behavior using a simple, human-readable format. These files serve as a bridge between business requirements and automation scripts, ensuring clear communication among developers, testers, and stakeholders.

Key Components of Feature Files

1. Feature Description:
   • A high-level summary of the functionality being tested.
   • Helps in understanding the purpose of the test.
     
2. Scenarios:
   • Each scenario represents a specific test case.
   • Follows a structured Given-When-Then format for clarity.
     
3. Scenario Outlines (Parameterized Tests):
   • Used when multiple test cases follow the same pattern but with different inputs.
   • Allows for better test coverage with minimal duplication.
     
4. Tags for Organization:
   • Tags like @smoke, @regression, or @critical help in organizing and running selective tests.
   • Makes it easier to filter and execute relevant scenarios.

Web App Automation Feature File: 

Feature: Perform basic calculator operations

    Background:
        Given I visit calculator web page

    @smoke
    Scenario Outline: Verify the calculator operations for scientific calculator
        When I click on number "<num1>"
        And I click on operator "<Op>"
        And I click on number "<num2>"
        Then I see the result as "<res>"
        Examples:
            | num1 | Op | num2 | res |
            | 6    | /  | 2    | 3   |
            | 3    | *  | 2    | 6   |

    @smoke1
    Scenario: Verify the basic calculator operations with parameter
        When I click on number "7"
        And I click on operator "+"
        And I click on number "5"
        Then I see the result as "12"

API Automation Feature File:

Feature: API Feature

    @api
    Scenario: Verify the GET call for dummy website
        When I send a 'GET' request to 'api/users?page=2' endpoint
        Then I Verify that a 'GET' request to 'api/users?page=2' endpoint returns status

    @api
    Scenario: Verify the DELETE call for dummy website
        When I send 'POST' request to endpoint 'api/users/2'
            | name     | job    |
            | morpheus | leader |
        Then I verify the POST call
            | req  | endpoint  | name     | job           | status |
            | POST | api/users | morpheus | zion resident | 200    |

    @api
    Scenario: I send POST Request call and Verify the POST call Using Step Reusablity
         When I send 'POST' request to endpoint 'api/users/2'
            | req  | endpoint  | name     | job           |
            | POST | api/users | morpheus | zion resident |
        Then I verify the POST call
            | req  | endpoint  | name     | job           | status |
            | POST | api/users | morpheus | zion resident | 200    |

Step Definition File: 

Step definition files act as the implementation layer for feature files. They contain the actual automation logic that executes each step in a scenario. These files ensure that feature files remain human-readable while the automation logic is managed separately.

Key Components of Step Definition Files

1. Mapping Steps to Code:
   • Each Given, When, and Then step in a feature file is linked to a function in the step definition file.
   • Ensures test steps execute the corresponding automation actions.
     
2. Reusability and Modularity:
   • Common steps can be reused across multiple scenarios.
   • Avoid duplication and improve maintainability.
     
3. Data Handling:
   • Step definitions can take parameters from feature files to execute dynamic tests.
   • Enhances flexibility and test coverage.
     
4. Error Handling & Assertions:
   • Verifies expected outcomes and reports failures accurately.
   • Helps in debugging test failures efficiently.

Web App Step Definition File:

import { When, Then, Given } from '@badeball/cypress-cucumber-preprocessor'
import { CalPage } from '../../../page-objects/CalPage'
const calPage = new CalPage()

Given('I visit calculator web page', () => {
  calPage.visitCalPage()
  cy.wait(6000)
})

Then('I see the result as {string}', (result) => {
  calPage.getCalculationResult(result)
  calPage.scrollToHeader()
})

When('I click on number {string}', (num1) => {
  calPage.clickOnNumber(num1)
  calPage.scrollToHeader()
})

When('I click on operator {string}', (Op) => {
  calPage.clickOnOperator(Op)
  calPage.scrollToHeader()
})

API Step Definition File:

import { Given, When, Then } from '@badeball/cypress-cucumber-preprocessor'
import { APIUtility } from '../../../../Utility/APIUtility'

const apiPage = new APIUtility()

When('I send a {string} request to {string} endpoint', (req, endpoint) => {
  apiPage.getQuery(req, endpoint)
})

Then(
  'I Verify that a {string} request to {string} endpoint returns status',
  (req, endpoint) => {
    apiPage.iVerifyGETRequest(req, endpoint)
  },
)

Then('I verify that {string} request to {string} endpoint', (datatable) => 
  apiPage.postQueryCreate(datatable)
})

Then('I verify the POST call', (datatable) => {
  apiPage.postQueryCreate(datatable)
})

When('I send {string} request to endpoint {string}', (req, endpoint) => {
  apiPage.delQueryReq(req, endpoint)
})

Then(
  'I verify {string} request to endpoint {string} returns status',
  (req, endpoint) => {
    apiPage.delQueryReq(req, endpoint)
  },
)

Page File:

Page files in test automation frameworks serve as a structured way to interact with web pages while keeping test scripts clean and maintainable. These files typically encapsulate locators and actions related to a specific page or component within the application under test.

Key Components of Page Files in Test Automation Frameworks

1. Navigation Methods:
   • Functions to visit the required page using a URL or base configuration.
   • Ensures tests always start from the correct application state.
     
2. Element Interaction Methods:
   • Functions to interact with buttons, input fields, dropdowns, and other UI elements.
   • Encapsulates actions like clicking, typing, or selecting options to maintain reusability.
     
3. Assertions and Validations:
   • Methods to verify expected outcomes, such as checking if an element is visible or a value is displayed correctly.
   • Helps in ensuring the application behaves as expected.
     
4. Reusability and Modularity:
   • Each function is designed to be reusable across multiple test cases.
   • Keeps automation scripts clean by avoiding redundant code.
     
5. Handling Dynamic Elements:
   • Includes waits, scrolling, or retries to ensure elements are available before interaction.
   • Reduces flakiness in tests.
     
6. Test Data Handling:
   • Functions to pass dynamic test data and execute actions accordingly.
   • Enhances flexibility and improves test coverage.

/// <reference types="cypress" />

import cypress = require('cypress')

export class CalPage {
  visitCalPage() {
    cy.visit(Cypress.config('baseUrl'))
  }

  scrollToHeader() {
    return cy
      .get(
        'img[src="//d26tpo4cm8sb6k.cloudfront.net/img/svg/calculator-white.svg"]',
      )
      .scrollIntoView()
  }

  clickOnNumber(number) {
    return cy.get('span[onclick="r(' + number + ')"]').click()
  }

  clickOnOperator(operator) {
    return cy.get(`span[onclick="r('` + operator + `')"]`).click()
  }

  getCalculationResult(result) {
    cy.get('span[onclick="r(\'=\')"]').click()
    cy.get('#sciOutPut').should('contain', result)
  }

  clickOnNumberSeven() {
    cy.get('span[onclick="r(7)"]').click()
  }

  clickOnMinusOperator() {
    cy.get('span[onclick="r(\'-\')"]').click()
  }

  clickOnNumberFive() {
    cy.get('span[onclick="r(5)"]').click()
  }

  getResult() {
    cy.get('span[onclick="r(\'=\')"]').click()
    cy.get('#sciOutPut').should('contain', '2')
  }

  EnterNumberOnCalculatorPage(datatable) {
    datatable.hashes().forEach((element) => {
      cy.get('span[onclick="r(' + element.num1 + ')"]').click()
      cy.get('span[onclick="r(\'' + element.Op + '\')"]').click()
      cy.get('span[onclick="r(' + element.num2 + ')"]').click()
      cy.get('#sciOutPut').should('contain', '' + element.res + '')
      cy.get('span[onclick="r(\'C\')"]').click()
    })
  }

  IVerifyResult(res) {
    cy.get('#sciOutPut').should('contain', '' + res + '')
    cy.get('span[onclick="r(\'C\')"]').click()
  }
}

API Utility File:

API utility files are essential in automated testing as they provide reusable methods to interact with APIs. These files help testers perform API requests, validate responses, and maintain structured automation scripts.

By centralizing API interactions in a dedicated utility, we can improve test maintainability, reduce duplication, and ensure consistent validation of API responses.

Key Components of an API Utility File:

1. Making API Requests Efficiently:
   • Functions for sending GET, POST, PUT, and DELETE requests.
   • Uses dynamic parameters to handle different endpoints and request types.
     
2. Response Validation & Assertions:
   • Ensures correct HTTP status codes are returned.
   • Validates response bodies for expected data formats.
     
3. Logging & Debugging:
   • Captures API request and response details for debugging.
   • Provides meaningful logs to assist in troubleshooting failures.
     
4. Handling Dynamic Data:
   • Supports dynamic payloads using external test data sources.
   • Allows testing multiple scenarios without modifying the core test script.
     
5. Error Handling & Retry Mechanism:
   • Implements error handling to manage unexpected API failures.
   • Can include automatic retries for transient errors (e.g., 429 rate limiting).
     
6. Security & Authentication Handling:
   • Supports authentication headers (e.g., tokens, API keys).
   • Ensures tests adhere to security best practices like encrypting sensitive data.

/// <reference types="cypress" />

export class APIUtility {
  getQuery(req, endpoint) {
    cy.request(req, Cypress.env('api_URL') + endpoint)
  }

  iVerifyGETRequest(req, endpoint) {
    cy.request(req, Cypress.env('api_URL') + endpoint).then((response) => {
      expect(response).to.have.property('status', 200)
    })
  }

  postQueryCreate(datatable) {
    datatable.hashes().forEach((element) => {
      const body = { name: element.name, job: element.job }
      cy.log(JSON.stringify(body))
      cy.request(element.req, Cypress.env('api_URL') + 'api/users', body).then(
        (response) => {
          expect(response).to.have.property('status', 201)
          cy.log(JSON.stringify(response.body.name))
          expect(response.body.name).to.eql(element.name)
        },
      )
    })
  }

  putQueryReq(req, job) {
    cy.request(req, Cypress.env('api_URL') + 'api/users/2', job).then(
      (response) => {
        expect(response).to.have.property('status', 200)
        expect({ name: 'morpheus', job: job }).to.eql({
          name: 'morpheus',
          job: job,
        })
      },
    )
  }

  delQueryReq(req, endpoint) {
    cy.request(req, Cypress.env('api_URL') + endpoint).then((response) => {
      expect(response).to.have.property('status', 201)
    })
  }
}

Possible Improvements in the API Utility File:

1. Add Environment-Based Configuration:
   • Currently, the base URL is fetched from Cypress.env(‘api_URL’), but we can extend it to support multiple environments (e.g., dev, staging, prod).
     
2. Enhance Error Handling & Retry Logic:
   • Implement a retry mechanism for APIs that occasionally fail due to network issues.
   • Improve error messages by logging API response details when failures occur.
     
3. Support Query Parameters & Headers:
   • Modify functions to accept optional query parameters and custom headers for better flexibility.
     
4. Improve Response Validation:
   • Extend validation beyond just checking the status code (e.g., validating response schema using JSON schema validation).
     
5. Use Utility Functions for Reusability:
   • Extract common assertions (e.g., checking response status, verifying keys in the response) into separate utility functions to avoid redundancy.
     
6. Implement Rate Limiting Controls:
   • Introduce a delay between API requests in case of rate-limited endpoints to prevent hitting request limits.
     
7. Better Logging & Reporting:
   • Enhance logging to provide detailed information about API requests and responses.
   • Integrate with test reporting tools to generate detailed API test reports.

Configuration Files:

Cypress.config.ts:

The Cypress configuration file (cypress.config.ts) is essential for defining the setup, plugins, and global settings for test execution. It helps in configuring test execution parameters, setting up plugins, and customizing Cypress behavior to suit the project’s needs.

This file ensures that Cypress is properly integrated with necessary preprocessor plugins (like Cucumber and Allure) while defining critical environment variables and paths.

Key Components of the Configuration File:

1. Importing Required Modules & Plugins:
   • Cypress needs additional plugins for Cucumber support and reporting.
   • @badeball/cypress-cucumber-preprocessor is used for running .feature files with Gherkin syntax.
   • @shelex/cypress-allure-plugin/writer helps in generating test execution reports using Allure.
   • @esbuild-plugins/node-modules-polyfill ensures compatibility with Node.js modules.
     
2. Setting Up Event Listeners & Preprocessors:
   • The setupNodeEvents function is responsible for handling plugins and configuring Cypress behavior dynamically.
   • The Cucumber preprocessor generates JSON reports and processes Gherkin-based test cases.
   • Browserify is used as the file preprocessor, allowing TypeScript support in tests.
     
3. Environment Variables & Custom Configurations:
   • api_URL: Stores the base API URL used for API testing.
   • screenshotsFolder: Defines the folder where Cypress will save screenshots in case of failures.
     
4. Defining E2E Testing Behavior:
   • setupNodeEvents: Attaches the preprocessor and other event listeners.
   • excludeSpecPattern: Ensures Cypress does not pick unwanted file types (*.js, *.md, *.ts).
   • specPattern: Specifies that Cypress should look for .feature files in cypress/e2e/.
   • baseUrl: Defines the website URL where tests will be executed (https://www.calculator.net/).

import { defineConfig } from 'cypress'
import { addCucumberPreprocessorPlugin } from '@badeball/cypress-cucumber-preprocessor'
import browserify from '@badeball/cypress-cucumber-preprocessor/browserify'

import allureWriter from '@shelex/cypress-allure-plugin/writer'
const {
  NodeModulesPolyfillPlugin,
} = require('@esbuild-plugins/node-modules-polyfill')

async function setupNodeEvents(
  on: Cypress.PluginEvents,
  config: Cypress.PluginConfigOptions,
): Promise<Cypress.PluginConfigOptions> {
  // This is required for the preprocessor to be able to generate JSON reports after each run, and more,
  await addCucumberPreprocessorPlugin(on, config)
  allureWriter(on, config),
    on(
      'file:preprocessor',
      browserify(config, {
        typescript: require.resolve('typescript'),
      }),
    )

  // Make sure to return the config object as it might have been modified by the plugin.
  return config
}
export default defineConfig({
  env: {
    api_URL: 'https://reqres.in/',
    screenshotsFolder: 'cypress/screenshots',
  },

  e2e: {
    // We've imported your old cypress plugins here.
    // You may want to clean this up later by importing these.

    setupNodeEvents,

    excludeSpecPattern: ['*.js', '*.md', '*.ts'],
    specPattern: 'cypress/e2e/**/*.feature',
    baseUrl: 'https://www.calculator.net/',
  },
})

Tsconfig.json:

The tsconfig.json file is a TypeScript configuration file that defines how TypeScript code is compiled and interpreted in a Cypress test automation framework. It ensures that Cypress and Node.js types are correctly recognized, allowing TypeScript-based test scripts to function smoothly.

Key Components of tsconfig.json:

1. compilerOptions (Compiler Settings)
   • “esModuleInterop”: true
     • Allows interoperability between ES6 modules and CommonJS modules, enabling seamless imports.
   • “target”: “es5”
     • Specifies that the compiled JavaScript should be compatible with ECMAScript 5 (older browsers and environments).
   • “lib”: [“es5”, “dom”]
     • Includes support for ES5 and browser-specific APIs (DOM), ensuring compatibility with Cypress test scripts.
   • “types”: [“cypress”, “node”]
     • Adds TypeScript definitions for Cypress and Node.js, preventing type errors in test scripts.
       
2. include (Files Included for Compilation)
   • **/*.ts
     • Ensures that all TypeScript files in the project directory are included in compilation.
   • “cypress/e2e/Features/step_definitions/Reports.js”
     • Explicitly includes a JavaScript step definition file related to reports.
   • “cypress/support/commands.ts”
     • Ensures that custom Cypress commands (written in TypeScript) are compiled and recognized.
   • “cypress/e2e/Features/step_definitions/*.ts”
     • Includes all step definition TypeScript files to be processed for test execution.

{
  "compilerOptions": {
    "esModuleInterop": true,
    "target": "es5",
    "lib": ["es5", "dom"],
    "types": ["cypress", "node"]
  },
  "include": [
    "**/*.ts",
    "cypress/e2e/Features/step_definitions/Reports.js",
    "cypress/support/commands.ts",
    "cypress/e2e/Features/step_definitions/*.ts"
  ]
}

Package.json

The package.json file is a key component of a Cypress-based test automation framework that defines project metadata, dependencies, scripts, and configurations. It helps manage all the required libraries and tools needed for running, reporting, and processing test cases efficiently.

Key Components of package.json:

1. Project Metadata
   • “name”: “spurtype” → Defines the project name.
   • “version”: “1.0.0” → Specifies the current project version.
   • “description”: “Cypress With TypeScript” → Describes the purpose of the project.
     
2. Scripts (Commands for Running Tests & Reports)
   • “scr”: “node cucumber-html-report.js”
     • Runs a script to generate a Cucumber HTML report.
   • “coms”: “cucumber-json-formatter –help”
     • Displays help information for Cucumber JSON formatter.
   • “api”: “./node_modules/.bin/cypress-tags run -e TAGS=@api”
     • Executes Cypress tests tagged as API tests (@api).
   • “smoke”: “./node_modules/.bin/cypress-tags run -e TAGS=@smoke”
     • Executes smoke tests (@smoke) using Cypress.
   • “smoke4”: “cypress run –env allure=true,TAGS=@smoke1”
     • Runs a specific set of smoke tests (@smoke1) while enabling Allure reporting.
   • “allure:report”: “allure generate allure-results –clean -o allure-report”
     • Generates a test execution report using Allure and stores it in allure-report.
       
3. Report Configuration
   • “json” → Enables JSON logging and sets the output file location.
   • “messages” → Enables message logging in NDJSON format.
   • “html” → Enables HTML report generation.
   • “stepDefinitions” → Specifies the location of Cucumber step definition files (.ts).
     
4. Development Dependencies (devDependencies)
   • @shelex/cypress-allure-plugin → Integrates Allure for test reporting.
   • @types/cypress-cucumber-preprocessor → Provides TypeScript definitions for Cucumber preprocessor.
   • cucumber-html-reporter, multiple-cucumber-html-reporter → Used for generating detailed Cucumber test reports.
   • cypress-cucumber-preprocessor → Enables running Cucumber feature files with Cypress.
     
5. Dependencies (dependencies)
   • @badeball/cypress-cucumber-preprocessor → Official Cucumber preprocessor for Cypress.
   • @cypress/code-coverage → Enables code coverage analysis for tests.
   • allure-commandline → Provides command-line tools to generate Allure reports.
   • typescript → Ensures TypeScript support in the test framework.
     
6. Cypress Cucumber Preprocessor Configuration
   • “filterSpecs”: true → Runs only test files that match the specified tags.
   • “omitFiltered”: true → Excludes test cases that do not match the filter criteria.
   • “stepDefinitions”: “./cypress/e2e/**/*.{js,ts}” → Specifies the path for step definition files.
   • “cucumberJson”
     • “generate”: true → Enables generation of Cucumber JSON reports.
     • “outputFolder”: “cypress/cucumber-json” → Stores JSON reports in the specified folder.

{
  "name": "spurtype",
  "version": "1.0.0",
  "description": "Cypress With TypeScript",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "scr": "node cucumber-html-report.js",
    "coms": "cucumber-json-formatter --help",
    "api": "./node_modules/.bin/cypress-tags run -e TAGS=@api",
    "smoke": "./node_modules/.bin/cypress-tags run -e TAGS=@smoke",
    "smoke4": "cypress run --env allure=true,TAGS=@smoke1",
    "allure:report": "allure generate allure-results --clean -o allure-report"
  },
  "json": {
    "enabled": true,
    "output": "jsonlogs/log.json",
    "formatter": "cucumber-json-formatter.exe"
  },
  "messages": {
    "enabled": true,
    "output": "jsonlogs/messages.ndjson"
  },
  "html": {
    "enabled": true
  },
  "stepDefinitions": [
    "cypress/e2e/Features/step_definitions/*.ts"
  ],
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "@shelex/cypress-allure-plugin": "^2.34.0",
    "@types/cypress-cucumber-preprocessor": "^4.0.1",
    "cucumber-html-reporter": "^5.5.0",
    "cypress": "^12.14.0",
    "cypress-cucumber-preprocessor": "^4.3.0",
    "multiple-cucumber-html-reporter": "^1.21.6"
  },
  "dependencies": {
    "@badeball/cypress-cucumber-preprocessor": "^15.1.0",
    "@bahmutov/cypress-esbuild-preprocessor": "^2.1.5",
    "@cucumber/pretty-formatter": "^1.0.0",
    "@cypress/browserify-preprocessor": "^3.0.2",
    "@cypress/code-coverage": "^3.10.0",
    "@esbuild-plugins/node-modules-polyfill": "^0.1.4",
    "allure-commandline": "^2.20.1",
    "cypress-esbuild-preprocessor": "^1.0.2",
    "esbuild": "^0.15.11",
    "json-combiner": "^2.1.0",
    "tsify": "^5.0.4",
    "typescript": "^4.4.4"
  },
  "cypress-cucumber-preprocessor": {
    "filterSpecs": true,
    "omitFiltered": true,
    "stepDefinitions": "./cypress/e2e/**/*.{js,ts}",
    "cucumberJson": {
      "generate": true,
      "outputFolder": "cypress/cucumber-json",
      "filePrefix": "",
      "fileSuffix": ""
    }
  }
}

Report Configuration Files:

Cucumber-html-report.js:

This script generates a Cucumber HTML report from JSON test results using the multiple-cucumber-html-reporter package. It extracts test execution details, including browser, platform, and environment metadata, and saves the output as an HTML file for easy visualization of test results in Cypress and TypeScript Automation.

const report = require('multiple-cucumber-html-reporter');

report.generate({
    jsonDir: "./GenerateReports",  // ** Path of .json file **//
    reportPath: "./Output", // ** Path of .html file **//
    metadata: {
        browser: {
            name: "chrome",
            version: "92",
        },
        device: "Local test machine",
        platform: {
            name: "windows",
            version: "10",
        },
    },
});

Explanation of Key Components

1. Importing multiple-cucumber-html-reporter
   • The script requires the package to process JSON reports and generate an interactive HTML report.
     
2. Configuration Options
   • jsonDir → Specifies the location of Cucumber-generated JSON reports.
   • reportPath → Sets the directory where the HTML report will be saved.
   • reportName → Defines a custom name for the report file.
   • pageTitle → Sets the title of the generated HTML report page.
   • displayDuration → Enables duration display for each test case execution.
   • openReportInBrowser → Automatically opens the HTML report after generation.
     
3. Metadata Section
   • Browser: Specifies the test execution browser and version.
   • Device: Identifies the test execution machine.
   • Platform: Defines the operating system used for testing.
     
4. Custom Data Section
   • Provides additional test details such as Project Name, Test Environment, Execution Time, and Tester Information.

Cypress-cucumber-preprocessor.json

This JSON configuration file is primarily used to manage the Cypress Cucumber preprocessor settings. It enables JSON logging, message output, and HTML report generation, and it specifies the location of step definition files.

{
  "json": {
    "enabled": true,
    "output": "jsonlogs/log.json",
    "formatter": "cucumber-json-formatter.exe"
  },
  "messages": {
    "enabled": true,
    "output": "jsonlogs/messages.ndjson"
  },
  "html": {
    "enabled": true
  },

  "stepDefinitions": ["cypress/e2e/Features/step_definitions/*.ts"]
}

Explanation of Configuration Parameters

1. JSON Report Configuration (json)
   • enabled: true → Ensures JSON report generation is active.
   • output: “jsonlogs/log.json” → Specifies the path where the JSON log file will be stored.
   • formatter: “cucumber-json-formatter.exe” → Defines the formatter used for generating Cucumber JSON reports.
     
2. Messages Configuration (messages)
   • enabled: true → Enables the logging of execution messages.
   • output: “jsonlogs/messages.ndjson” → Specifies the path where test execution messages will be stored in NDJSON format.
     
3. HTML Report Configuration (html)
   • enabled: true → Enables HTML report generation, allowing better visualization of test results.
     
4. Step Definitions Configuration (stepDefinitions)
   • “stepDefinitions”: [“cypress/e2e/Features/step_definitions/*.ts”]
   • Specifies the directory where step definition files are located. These files contain the implementation for Gherkin feature file steps.

Conclusion:

Cypress and TypeScript together create a powerful and efficient framework for both web applications and API automation. By leveraging Cypress’s fast execution and robust automation capabilities alongside TypeScript’s strong typing and code scalability, we can build reliable, maintainable, and scalable test suites.

With features like Cucumber BDD integration, JSON reporting, HTML test reports, and API automation utilities, Cypress enables seamless test execution, while TypeScript enhances code quality, error handling, and developer productivity. The structured approach of defining page objects, API utilities, and configuration files ensures a well-organized framework that is both flexible and efficient.

As automation testing continues to evolve, integrating Cypress with TypeScript proves to be a future-ready solution for modern software testing needs. Whether it’s UI automation, API validation, or end-to-end testing, this dynamic combination offers speed, accuracy, and maintainability, making it an essential choice for testing high-quality web applications.

Github Link:

https://github.com/spurqlabs/SpurCypressTS

Click here to read more blogs like this.

Yogesh Dhole

Top-Tier SDET | Advanced in Manual & Automated Testing | Skilled in Full-Spectrum Testing & CI/CD | API & Mobile Automation | Desktop App Automation | ISTQB Certified